Re: HTTPS trust anchors in sysinst

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Sat, 26 Aug 2023 15:28:57 +0200
> From: Martin Husemann <martin%duskware.de@localhost>
> 
> On Sat, Aug 26, 2023 at 12:46:48PM +0000, Taylor R Campbell wrote:
> > There's a few different mechanisms to put files into install media,
> > depending on the install media, and I'm not clear on how they all work
> > and fit together, so maybe someone can help me decide what to do.
> > 
> > - For ramdisks, we can create, say, a src/distrib/common/list.certs
> >   which installs cert.pem, and add that to LISTS.
> 
> Many ram disk images are very size restrained and this will be a challenge.
> We struggle for every single byte on many of them.

That's what I figured.  Partly I wanted to find out: Is this where
they would need to go in order to be available to sysinst at
/etc/openssl/cert.pem when sysinst runs, or does the ramdisk get
union-mounted with another file system where the cert.pem file could
live instead?

Ideally I'd like a summary of how the installers work on each
platform, with a side-by-side comparison of mechanisms and limits and
stuff.  But realistically I suppose that's just encoded in the nest of
makefiles under src/distrib/ and not summarized anywhere.

> > - For install images (USB images -- maybe also CD images?), it looks
> >   like we can add cert.pem to IMGFILE_EXTRA.
> 
> For proper CD images (e.g. amd64, vax, sparc64) the certs should just
> be there due to being in base.tgz. Can we just create the missing symlinks
> for them to be usable?

The symlink names are formed by hashing the public key subject name.
This requires parsing the certificates and computing the hash, both of
which are nontrivial to do with the tools available at build-time.

Perhaps we could precompute this information on regen and commit it to
the *.trust lists that are used to decide which files go in
/usr/share/certs/mozilla/server.

But that's more engineering and I'm hoping to keep the rehashing logic
limited to a single path in certctl(8) that invokes `openssl rehash'
itself, so we don't have multiple versions of the logic floating
around that might work in subtly different ways or get out of sync if
the directory format changes.

> > - Not sure about floppies (FLOPPYFILES?), but this is a path that we
> >   may be able to test easily because it's how anita bootstraps anyway!
> >   Of course, it might bump us to one more floppy.
> 
> Anita only uses floppies by default on a few platforms (like x86).
> We struggle for every single byte on many floppy images too.

Right, but

(a) that doesn't really matter for anita since it can simulate
handling as many floppies as it needs, and

(b) how much does the number of floppies matter in practice for real
hardware?  Are there people actually installing NetBSD on real
hardware with floppies, who will get bored and give up if there are
seven floppies but won't get bored if there are six?

> Overall I have no good/helpfull answer but expect this to be a non trivial
> change.

Sure -- so we can start by focussing on amd64, where it is not too
painful to contemplate, and we can provide the tools to expand it
incrementally to other ports.

Or maybe we can decide this isn't worthwhile, and the effort is better
spent on a lighter-weight signing system for NetBSD distributions,
where a set of trust anchor public keys for 2-of-3 threshold
verification can be around 3*32 bytes plus formatting (though this
will also increase the code size, of course).