HTTPS trust anchors in sysinst

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

We now install Mozilla's HTTPS trust anchors in base.

However, the install media aren't built with them.

For installers that don't have sets built-in, and instead fetch them
over the network with ftp(1) -- or install packages with pkg_add(1) --
I'd like to use the Mozilla trust anchors for HTTPS[*].

To do this, we need to put into the install media either:

(a) a hashed directory of certs at /etc/openssl/certs, or
(b) a flat file of concatenated PEM certs at /etc/openssl/cert.pem.

Creating a hashed directory requires running openssl(1) or similar,
which is not built as a tool and not required to be available in the
host environment at build-time.  So (b) will probably be easier.

The total size is about 210 KB right now.

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.

  Small snag: it can't reach into objdirs, only srcdir or destdir.  So
  if we want to put it in any ramdisks, we might have to pregenerate
  cert.pem and check it in to src -- not too bad.  (Would prefer not
  to install it into the destdir so we don't have a cache baked into
  etc.tgz.)

- For install images (USB images -- maybe also CD images?), it looks
  like we can add cert.pem to IMGFILE_EXTRA.

  Maybe also live-image for x86, not sure if this applies to the
  non-x86 live images like arm.img, arm64.img, octeon.img.

- 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.

So how should we wire this up to make it available to sysinst?


[*] We should _also_ bake a public signature verification key into the
    installers that can verify a signature on the sets which can in
    turn be made only by TNF -- not by any of the public HTTPS CAs.
    But that's a separate issue that requires more key management and
    software verifier setup than we have settled now.

    I am also open to the possibility of having a way to override the
    trust anchors at build-time or a utility menu entry to override
    them at run-time.  But for custom installers, I think overriding
    HTTPS trust anchors is a lower priority than hooks for key
    management and signature verification.  And while that in turn may
    not be lower priority using HTTPS trust anchors, using HTTPS trust
    anchors is certainly lower _effort_ to get working now.