daily CVS update output

[NetBSD source update]

Updating src tree:
P src/distrib/evbmips/instkernel/ramdisk/Makefile
P src/doc/3RDPARTY
P src/external/gpl3/gcc.old/dist/gcc/dse.c
P src/lib/libm/Makefile
P src/sys/arch/mipsco/include/bus.h
P src/sys/arch/mipsco/include/isa_machdep.h
P src/sys/arch/mipsco/isa/isa_machdep.c
P src/sys/arch/news68k/news68k/locore.s
P src/sys/arch/news68k/news68k/machdep.c
P src/sys/arch/news68k/news68k/pmap_bootstrap.c
P src/sys/arch/news68k/news68k/vectors.s
P src/sys/arch/news68k/stand/bootxx/start.S
P src/sys/ddb/db_xxx.c
P src/sys/dev/pci/pcidevs
P src/sys/dev/pci/pcidevs.h
P src/sys/dev/pci/pcidevs_data.h
P src/sys/kern/kern_condvar.c
P src/sys/kern/kern_exec.c
P src/sys/kern/kern_exit.c
P src/sys/kern/kern_sleepq.c
P src/sys/kern/kern_timeout.c
P src/sys/kern/kern_turnstile.c
P src/sys/kern/sys_lwp.c
P src/sys/kern/sys_select.c
P src/sys/rump/librump/rumpkern/sleepq.c
P src/sys/sys/sleepq.h
P src/sys/sys/syncobj.h
P src/tools/gcc/gcc-version.mk

Updating xsrc tree:


Killing core files:



Updating release-8 src tree (netbsd-8):
U doc/CHANGES-8.3
P sys/dev/pci/if_wm.c
P sys/dev/pci/ixgbe/ix_txrx.c
P sys/dev/pci/ixgbe/ixgbe.c
P sys/dev/pci/ixgbe/ixgbe.h
P sys/dev/pci/ixgbe/ixgbe_82599.c
P sys/dev/pci/ixgbe/ixgbe_mbx.h
P sys/dev/pci/ixgbe/ixgbe_type.h
P sys/dev/pci/ixgbe/ixgbe_vf.c
P sys/dev/pci/ixgbe/ixgbe_vf.h
P sys/dev/pci/ixgbe/ixv.c

Updating release-8 xsrc tree (netbsd-8):



Updating release-9 src tree (netbsd-9):
P distrib/evbmips/instkernel/ramdisk/Makefile
U doc/CHANGES-9.4
P lib/libm/Makefile
P sys/dev/pci/if_wm.c
P sys/dev/pci/ixgbe/ix_txrx.c
P sys/dev/pci/ixgbe/ixgbe.c
P sys/dev/pci/ixgbe/ixgbe.h
P sys/dev/pci/ixgbe/ixgbe_82599.c
P sys/dev/pci/ixgbe/ixgbe_mbx.h
P sys/dev/pci/ixgbe/ixgbe_type.h
P sys/dev/pci/ixgbe/ixgbe_vf.c
P sys/dev/pci/ixgbe/ixgbe_vf.h
P sys/dev/pci/ixgbe/ixv.c

Updating release-9 xsrc tree (netbsd-9):



Updating release-10 src tree (netbsd-10):
P crypto/external/bsd/openssh/lib/Makefile
P distrib/evbmips/instkernel/ramdisk/Makefile
P distrib/sets/lists/man/mi
P distrib/utils/x_ping/Makefile
P doc/CHANGES
U doc/CHANGES-10.0
P external/apache2/argon2/lib/libargon2/Makefile.inc
P external/bsd/jemalloc/lib/Makefile.inc
P external/bsd/mdocml/lib/libmandoc/Makefile
P external/gpl3/binutils/dist/gas/config/tc-vax.c
P external/gpl3/binutils/dist/gas/config/tc-vax.h
P external/gpl3/binutils/lib/libbfd/Makefile
P external/gpl3/binutils.old/lib/libbfd/Makefile
U external/gpl3/gcc/dist/gcc/dse.c
U external/gpl3/gcc/dist/gcc/function.c
U external/gpl3/gcc/dist/gcc/recog.c
U external/gpl3/gcc/dist/gcc/reload.c
U external/gpl3/gcc/dist/gcc/rtlanal.c
P external/gpl3/gcc/dist/gcc/target.def
U external/gpl3/gcc/dist/gcc/targhooks.c
P external/gpl3/gcc/dist/gcc/targhooks.h
P external/gpl3/gcc/dist/gcc/config/vax/builtins.md
P external/gpl3/gcc/dist/gcc/config/vax/elf.h
U external/gpl3/gcc/dist/gcc/config/vax/vax.c
P external/gpl3/gcc/dist/gcc/config/vax/vax.md
P external/gpl3/gcc/dist/gcc/doc/tm.texi
P external/gpl3/gcc/dist/gcc/doc/tm.texi.in
P external/gpl3/gcc/lib/Makefile.sanitizer
P external/gpl3/gcc/lib/libasan/Makefile
P external/gpl3/gcc/lib/liblsan/Makefile
P external/gpl3/gcc/lib/libubsan/Makefile
P external/gpl3/gcc/usr.bin/backend/Makefile
P external/gpl3/gcc/usr.bin/cc1/Makefile
P external/gpl3/gcc/usr.bin/cc1obj/Makefile
P external/gpl3/gcc/usr.bin/cc1objplus/Makefile
P external/gpl3/gcc/usr.bin/cc1plus/Makefile
P external/gpl3/gcc/usr.bin/gcc/Makefile
P external/gpl3/gcc/usr.bin/libdecnumber/Makefile
P external/gpl3/gcc/usr.bin/lto-dump/Makefile
P external/gpl3/gcc/usr.bin/lto1/Makefile
P external/gpl3/gdb/lib/libdecnumber/Makefile
P external/gpl3/gdb/lib/libgdb/Makefile
P external/gpl3/gdb.old/lib/libdecnumber/Makefile
P external/mit/xorg/lib/gallium/Makefile
P external/mit/xorg/lib/gallium.old/Makefile
P external/mit/xorg/lib/libX11/Makefile.libx11
P games/gomoku/Makefile
P games/phantasia/Makefile
P lib/i18n_module/UTF7/Makefile
P lib/libbz2/Makefile
P lib/libc/gdtoa/Makefile.inc
P lib/libcrypt/Makefile
P lib/libm/Makefile
P libexec/ld.elf_so/Makefile
P sbin/fsck_ffs/Makefile.common
P sbin/fsdb/Makefile
P sbin/newfs_ext2fs/Makefile
P sbin/ping/Makefile
P share/man/man4/Makefile
U share/man/man4/igc.4
P sys/arch/amd64/conf/ALL
P sys/arch/amd64/conf/GENERIC
P sys/arch/amd64/conf/XEN3_DOM0
P sys/arch/evbarm/conf/GENERIC64
P sys/arch/evbppc/conf/DHT
P sys/arch/vax/conf/Makefile.vax
P sys/dev/pci/files.pci
P sys/dev/pci/if_wm.c
P sys/dev/pci/pcidevs
P sys/dev/pci/pcidevs.h
P sys/dev/pci/pcidevs_data.h
U sys/dev/pci/igc/if_igc.c
U sys/dev/pci/igc/if_igc.h
U sys/dev/pci/igc/igc_api.c
U sys/dev/pci/igc/igc_api.h
U sys/dev/pci/igc/igc_base.c
U sys/dev/pci/igc/igc_base.h
U sys/dev/pci/igc/igc_defines.h
U sys/dev/pci/igc/igc_evcnt.h
U sys/dev/pci/igc/igc_hw.h
U sys/dev/pci/igc/igc_i225.c
U sys/dev/pci/igc/igc_i225.h
U sys/dev/pci/igc/igc_mac.c
U sys/dev/pci/igc/igc_mac.h
U sys/dev/pci/igc/igc_nvm.c
U sys/dev/pci/igc/igc_nvm.h
U sys/dev/pci/igc/igc_phy.c
U sys/dev/pci/igc/igc_phy.h
U 

Re: Problems with dhcpcd

[Lloyd Parkes]

On 8/10/23 15:30, Lloyd Parkes wrote:
I added some debugging to /libexec/dhcpcd-run-hooks and things started 
working ... better.


I created an empty file called /var/log/debug and added "exec >> 
/var/log/debug 2>&1" to the top of /libexec/dhcpcd-run-hooks.


With this change the hostname is reliably set by the time I ssh in to 
the Raspberry Pi after a reboot...


I found the problem. The syslog function in /libexec/dhcpcd-run-hooks 
tries to echo text to stdout/stderr and the shell script gets killed 
with SIGPIPE when it's being run in the background.


Commenting out the lines

case "$lvl" in
err|error)  echo "$interface: $*" >&2;;
*)  echo "$interface: $*";;
esac

allows the script to run correctly.

Adding the command 'trap "" PIPE' to /libexec/dhcpcd-run-hooks is 
another way that allows the script to run correctly.


Cheers,
Lloyd

Re: Call for testing: certctl, postinstall, TLS trust anchors

[Rhialto]

On Sun 08 Oct 2023 at 16:04:20 +, Taylor R Campbell wrote:
> As far as I'm aware, S/MIME is only ever seriously deployed within a
> single organization at a time (or a closed set of partnering
> organizations).  So I don't expect anything about it to seriously work
> out of the box and I have no idea what public CAs do about it.

mail/mutt supports S/MIME signing at least out of its box, but by
default it uses its own management program `smime_keys` to manage the
keys, stored in ~/.smime. That's the closest I know of.

Sometimes I receive a mail signed with S/MIME from some mailing list but
I don't think that mutt ever told me that the signature matched (due to
the certificates not being set up).

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert
\X/ There is no AI. There is just someone else's work.   --I. Rose


signature.asc
Description: PGP signature

Re: Call for testing: certctl, postinstall, TLS trust anchors

[Taylor R Campbell]

> Date: Sun, 08 Oct 2023 10:54:13 -0400
> From: Greg Troxel 
> 
> (I've been putting off thinking about and dealing with this due to
> juggling too many other things.)

No worries, glad you found some time to review it!

> Taylor R Campbell  writes:
> 
> > The new certctl(8) tool is provided to manage the TLS trust anchors
> > configured in /etc/openssl/certs with a simple way to change the
> > source of trust anchors or distrust individual ones -- and with a
> > manual override, if you would rather use another mechanism to do it,
> > like the commands available in the security/mozilla-rootcerts or
> > security/ca-certificates packages, or the special-purpose
> > security/mozilla-rootcerts-openssl package.
> 
> This says "TLS trust anchors", but I wonder if that's accurate.  Isn't
> this "pkix trust anchors, for which the most common case is TLS"?  I
> have not dug in to the openssl library calls, but my impression is that
> openssl the installed software does pkix validation in general, and the
> installed trust anchors will be used for invocations to validate pkix certs
> separately from TLS.

If you know of applications that uses /etc/openssl/certs on NetBSD (or
/etc/ssl/certs on FreeBSD, or /etc/pki/tls/certs on Fedora), or SSLDIR
in pkgsrc, to find trust anchors for anything other than TLS, I'd like
to hear about it.

My guess is that such cases are very rare if they exist at all, and
they are totally dominated by applications that rely on it for TLS
validation.

> After reading, I think what's going on is
> 
>   1) mozilla rootcert situation is a bit of a mess smantically

Not really.  The CAs are clearly marked in certdata.txt for different
purposes.  I imported the content according to the metadata about
Mozilla's trust; more below.

>   2) certctl is installing the subset that is intended for TLS

Correct.

You can also use the same certctl(8) program to install trust anchors
in another path for other purposes, like /etc/smime/certs.  I made
sure it would work (both for testing and for other possible uses) but
didn't lift a finger to make it happen because TLS is critical and
everything else is niche.

>   3) the installed certs will be used for all uses, not just TLS
>   (e.g. SMIME), and because certs intended for SMIME but not "server"
>   are missing, the wrong thing will happen sometimes, but because many
>   CAs do both (?) it will often be ok.

See above: if you know of applications that rely on /etc/openssl/certs
for S/MIME, and it's not just a joke (which most open-ended
interorganizational use of S/MIME that I'm aware of is --
intraorganizational uses managed by a corporate IT department purely
for internal or partner use aside), I'm curious to see.

>   4) This is all not obvious, and
>  a) It's not the least bit clear that the right thing is happening.
>  b) I expect ~nobody to understand this.

Is any of the text in the certctl(8) or hier(7) man pages unclear
about this?  I tried to clarify the purpose of /etc/openssl/certs for
TLS trust anchors specifically in that text.

> Looking in /usr/share/certs/mozilla, it continues to be non-obvious.
> The idea that 'all' has "untrusted CAs" seems crazy; if they aren't
> trusted, why are they in the root set, which is by definition the set of
> CAs which meet the rules and are therefore trustworthy?

`all' has everything in certdata.txt.

`server' has only what Mozilla has chosen to trust for TLS.

`email' has only what Mozilla has chosen to trust for S/MIME.

> I see code is empty.  I'm going to ignore this.

Yes.  The certdata.txt format has a way to say that trust anchors are
fit for code-signing, so for completeness I exposed that via the
directory /usr/share/certs/mozilla/code, but (a) there are no trust
anchors in certdata.txt that use it, and (b) there is nothing in
NetBSD that would use such trust anchors anyway.

> With a bit of ls/sort/uniq/comm, I see that there are certs in all that
> do not appear in email or server:
> 
>   Explicitly_Distrust_DigiNotar_Root_CA.pem
>   Symantec_Class_1_Public_Primary_Certification_Authority_-_G6.pem
>   Symantec_Class_2_Public_Primary_Certification_Authority_-_G6.pem
>   TUBITAK_Kamu_SM_SSL_Kok_Sertifikasi_-_Surum_1.pem
>   TrustCor_ECA-1.pem
>   TrustCor_RootCert_CA-1.pem
>   TrustCor_RootCert_CA-2.pem
>   Verisign_Class_1_Public_Primary_Certification_Authority_-_G3.pem
>   Verisign_Class_2_Public_Primary_Certification_Authority_-_G3.pem

That looks correct.  It matches what I see in certdata.txt and the
special annotation about Tubitak Kamu SM at
.  See
external/mpl/mozilla-certdata/share/Makefile for notes on how this
particular sausage is made.

These exclusions also match my knowledge of the history:

- Digi-Notar was infamously compromised by the Iranian state a decade
  ago.

- Symantec's CA was nixed after a series of certificate misissuance
  incidents and audit failures a few years ago:
  

Re: Call for testing: certctl, postinstall, TLS trust anchors

[Greg Troxel]

(I've been putting off thinking about and dealing with this due to
juggling too many other things.)

Taylor R Campbell  writes:

> The new certctl(8) tool is provided to manage the TLS trust anchors
> configured in /etc/openssl/certs with a simple way to change the
> source of trust anchors or distrust individual ones -- and with a
> manual override, if you would rather use another mechanism to do it,
> like the commands available in the security/mozilla-rootcerts or
> security/ca-certificates packages, or the special-purpose
> security/mozilla-rootcerts-openssl package.

This says "TLS trust anchors", but I wonder if that's accurate.  Isn't
this "pkix trust anchors, for which the most common case is TLS"?  I
have not dug in to the openssl library calls, but my impression is that
openssl the installed software does pkix validation in general, and the
installed trust anchors will be used for invocations to validate pkix certs
separately from TLS.

After reading, I think what's going on is

  1) mozilla rootcert situation is a bit of a mess smantically
  2) certctl is installing the subset that is intended for TLS
  3) the installed certs will be used for all uses, not just TLS
  (e.g. SMIME), and because certs intended for SMIME but not "server"
  are missing, the wrong thing will happen sometimes, but because many
  CAs do both (?) it will often be ok.
  4) This is all not obvious, and
 a) It's not the least bit clear that the right thing is happening.
 b) I expect ~nobody to understand this.

Looking in /usr/share/certs/mozilla, it continues to be non-obvious.
The idea that 'all' has "untrusted CAs" seems crazy; if they aren't
trusted, why are they in the root set, which is by definition the set of
CAs which meet the rules and are therefore trustworthy?

I see code is empty.  I'm going to ignore this.

With a bit of ls/sort/uniq/comm, I see that there are certs in all that
do not appear in email or server:

  Explicitly_Distrust_DigiNotar_Root_CA.pem
  Symantec_Class_1_Public_Primary_Certification_Authority_-_G6.pem
  Symantec_Class_2_Public_Primary_Certification_Authority_-_G6.pem
  TUBITAK_Kamu_SM_SSL_Kok_Sertifikasi_-_Surum_1.pem
  TrustCor_ECA-1.pem
  TrustCor_RootCert_CA-1.pem
  TrustCor_RootCert_CA-2.pem
  Verisign_Class_1_Public_Primary_Certification_Authority_-_G3.pem
  Verisign_Class_2_Public_Primary_Certification_Authority_-_G3.pem

Looking at email vs server, I see 88 in common, 21 email only, 52 server
only.

How is SMIME supposed to work?  Are SMIME validators, which presumably
use openssl as an engine, supposed to maintain a different trust anchor
set?  Where? 

I see that mozilla-rootcerts-openssl has 169 certificates, so that must
be all, which appears to be a really serious bug.

Maybe we don't want to deal with this, but I think it needs to be
clearer, especially as this upgrade to certctl from
mozilla-rootcerts-openssl does:

  resolves a security issue where "untrusted" certs were trust anchors (yay)

  removes trust anchors for email, likely breaking some SMIME uses (but
  not sure in practice how much, given tbird uses internal and gpg2 uses
  gnutls).  (theoretical boo)


I'll also observe that it's mostly because I have avoide digging in
until today, but this larger situation of the subsets, what was and what
is, is news to me today.  

> So it would be helpful if you could test updating NetBSD in whatever
> way you do it (sysinst, untar/etcupdate/postinstall, etcmanage,
> something even more bespoke), and let me know if anything goes wrong
> with the TLS trust anchors:

I did an update via

  Existing system is netbsd-10 from august, upgraded since 2003 from
  netbsd-wicked-old, both software and hardware.

  Existing system has mozilla-rootcerts-openssl.

  Built release from netbsd-10 (normally via build.sh).

  Upgraded via INSTALL-NetBSD from etcmanage, which unpacks kernel and
  non-etc sets, unpacks etc/xetc to /usr/netbsd-etc and then runs
  etcmanage to merge those to /etc, never touching a user-modified
  file.

> 1. Does postinstall work smoothly for you?

Ran "postinstall -s /usr/netbsd-etc check", got warning about certctl,
which seems right.  Ran with fix, got:
  certctl: existing certificates; set manual or move them
which also seems right.

> 2. Does it blow away any configuration you had?  (I don't think it
>should, but if you back up /etc you should be able to see.)

The mozilla-rootcerts-openssl certs and one cert I had there manually
remain.  So correct behavior.

> 3. Do you end up with the trust anchors you expected?

I expect things I have changed in /etc not to be modified in an upgrade,
so yes.

Given the man page, I expected to have an empty /usr/openssl/untrusted
directory but that is not in any of the sets.  Perhaps the idea is that
it is created on demand, but I didn't figure that out from the man page.

> 4. Are the answers obvious or do you have to go digging?

I'm not a really good test case for this, but it seems pretty clear that

Re: cgd questions

[Taylor R Campbell]

> Date: Sun, 1 Oct 2023 14:50:20 +0200
> From: Thomas Klausner 
> 
> I tried finding this in the man page, but it wasn't fully clear to me.
> 
> When I pick up a cgd disk and want to use it on a NetBSD system to
> which it was not connected before, what do I need?
> 
> - the passphrase
> - the /etc/cgd/foo file?

Correct.

> If you need the /etc/cgd/foo file too, how do people handle those for
> cgds used as backup disks?

Save a copy somewhere else, e.g. printed out on paper or stored in a
USB flash drive.

> The other question is that the cgd man page says that some ciphers are
> obsolete. How can I switch from an obsolete cipher to a new one - is
> the only method to make a new cgd with the new cipher and copy the
> data manually?

Correct.

Perhaps it would be worthwhile to write a utility that does the
conversion incrementally in-place.  But it at least requires some
intermediate storage on another file system to do this safely, so it's
not entirely trivial -- cgd(4) itself uses no additional writable
storage, so there's nowhere for it to record how much of the volume
has been re-encrypted or to store a write-ahead or roll-back log of
each block it is re-encrypting in case of interruption.


> Date: Sun, 01 Oct 2023 09:31:03 -0400
> From: Greg Troxel 
> 
> Yes, you need the /etc/cgd/foo file because the passphrase is salted,
> and you might need an iv depending on iv method.  IMHO this is a design
> bug in cgd.  At least as a normal path, one should be able to access
> with just the passphrase.

On the contrary, this was a deliberate feature of cgd(4), precisely so
that you can store the parameters file separate from the disk, e.g. on
a small USB flash drive -- and, more importantly, so that you can
plausibly destroy the parameters file and safely recycle the disk.

See the Usenix 2003 paper on cgd
https://www.usenix.org/legacy/event/usenix03/tech/freenix03/full_papers/dowdeswell/dowdeswell.pdf
for details.

This design choice also obviates the need for cgd(4) to have its own
custom writable file system format and tooling like LUKS invented just
to store the parameters (which you have to store somewhere); instead
if you really want to store it side by side with the ciphertext, you
can do so with a small ffs partition on the disk, as you described.


> Date: Tue, 03 Oct 2023 15:53:33 -0400
> From: Greg Troxel 
> 
> Thomas Klausner  writes:
> 
> > IIUC the cgdconfig man page correctly, this is how you do that:
> >
> >  To create a new parameters file that will generate the same key as an 
> > old
> >  parameters file:
> >
> >  # cgdconfig -G -o newparamsfile oldparamsfile
> >  old file's passphrase:
> >  new file's passphrase:
> 
> I think what that does is encrypt the old key using the new passphrase,
> and store that encrypted key in the config file.  Thus you haven't
> changed the key, but you have a config file that allows decryption with
> a new passphrase.  That's good to give a second person access, but it
> doesn't revoke the first passphrase's access, if I understood correctly.

This revokes the first password's access if you also erase
oldparamsfile.

After all, the main value of cgd(4) -- aside from protecting from
theft of your disk while your laptop is turned off -- is that if you
can erase a short parameters file, that's enough to confidently erase
the disk before recycling it without having to worry about leaking
data through sector reassignment or wear-levelling or anything.

Note: The cgd parameters file does not contain the cgd(4) disk
encryption key -- not even an encrypted key.  It doesn't even contain
enough information to confirm a guess about the password.

So if you lose a USB flash drive with the parameters file, but you
don't lose the disk itself, it is useless to an adversary on its own
to guess your password.

(What it contains -- for password-based parameters -- is a random salt
that must be combined with the password to derive the disk encryption
key.)


> Date: Mon, 2 Oct 2023 09:46:10 +0200
> From: Thomas Klausner 
> 
> I have a USB Disk with ffs-on-cgd.  I unmounted the ffs but forgot
> unconfiguring the cgd before unplugging the disk.
> 
> Can this cause problems? What kinds?

It is unlikely to lead to any sort of data loss, because if you've
unmounted ffs, then it has closed the block device and thereby
synchronously flushed all pending writes.

If attempts to read from it or write to it fail in any way other than
returning EIO (e.g., crashing the system), or if you're unable to
unconfigure it with `cgdconfig -u', please file a PR and I'll take a
look.

cgd(4) _should_ handle this scenario gracefully.  But I say that
normatively or aspirationally rather than informatively of the status
quo.  We should find a way to automatically test this scenario too,
which I'm sure we don't right now.