Re: [PATCH] HTTPS/TLS CA certificates in base

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

> Date: Sun, 20 Aug 2023 22:32:38 +0100
> From: David Brownlee <abs%netbsd.org@localhost>
> 
> There was a previous thread that mooted the idea of using the project
> built mozilla-rootcerts packages (which are just tarfiles) as the
> source for some mechanism to populate on-system certificates, such as
> your proposed certctl. (mozilla-rootcerts is the base package which
> just populates into PREFIX, not mozilla-rootcerts-openssl which put
> data in /etc)
> 
> https://mail-index.netbsd.org/tech-userlevel/2023/08/04/msg014092.html

I considered that but I think this path requires too much of a Rube
Goldberg machine of moving parts to get working and maintain.  The
patch I posted is ready, today; took just two days of local work in my
spare time to draft and test; and puts no additional burden on releng
or package infrastructure.

> It would probably involve:
> - Ensuring that each quarterly package release put the latest
> mozilla-rootcerts in a Well Defined Location

Requires creating a new notion of architecture-independent packages
and a new well-defined location to put them and processes to build and
maintain them long-term.

certctl(8) already has an obvious place (base.tgz), which already has
established long-term processes to build and maintain.  It functions
like nsswitch as a point of system integration that can use built-in
parts (/usr/share/certs/mozilla) or be reconfigured with other
certificate sources you have the option of installing elsewhere.

> Which would give:
> - Always getting the latest certificates on install, whether
> installing 10.0 the moment its released, or in three years time

I expect in three years time there won't be much reason to install
10.0; instead it'll be 10.3 or 10.4.  And by that time (or well before
it), I'm hoping to have a cheaper idea of patch releases that can be
done on a weekly timescale and updated automatically so the 10.3
installer can promptly update to 10.3.17 with certificate updates --
and other security fixes.

> - The same location to pick up updated certificates for a previously
> installed system

True.  But I'm not sure it matters that much.  Anyone who really needs
the stability of an older release, like sborrill, can presumably just
build their own images with the package pre-included -- and is
probably already doing that.

> There is still the bootstrapping issue, which could be managed by any of:
> - Including just enough NetBSD certificates in base to make the initial download
> - Signed packages
> - Ignoring the issue and just installing over https without validation
> 
> The mechanism for getting the mozilla-rootcerts package data onto the
> system could be:
> 1) certctl Just Downloads And Extracts The Package Tarfile
> 2) Having the default sysinst flow install pkgin and mozilla-rootcerts
> (with opt-out), which also provides a ready mechanism to keep the data
> updated (pkgin upgrade)

My priority #1 here is to make netbsd-10 do TLS validation out of the
box with a reasonable, if not perfect, update story.  I don't want
that to be held up on any other major moving parts like signed
packages, pkgin, and base updates.

That's not to say these other moving parts aren't important to get
done, but I sifted through several avenues for getting them _all_ done
(some of which are sitting in my drafts as we speak), and decided that
this certctl(8) proposal has the best cost/reward ratio at the same
time as having the least risk for netbsd-10 as well as a clear path to
integration with future base updates and replacement by packages.

(With apologies for stepping on your toes about this --
architecture-neutral packaging may be a good idea but it's just not
going to be ready in a week and netbsd-10 is already extremely late.)