Re: Architecture neutral packages (mozilla-rootcerts-openssl)

[David Brownlee <abs%absd.org@localhost>]

On Fri, 4 Aug 2023 at 08:43, Martin Husemann <martin%duskware.de@localhost> wrote:
>
> On Thu, Aug 03, 2023 at 02:31:39PM +0000, John Klos wrote:
> > How it ultimately happens is up to people who understand things better than
> > I do, but what whould be lovely to see would be:
> >
> > 1) a way to install rootcerts in sysinst
> >
> > 2) a way to install them post-install, and/or update them
> >
> > 3) an easy way for people who have reasons to be deliberate to allow /
> >    block certain certs so that updates don't undo their work
>
> That is exactly what I'd like to see too. I will do (1) immediately
> once the other two are designed/agreed.
>
> I also think that this is NOT a pkgsrc problem, BUT pkgsrc has two very
> nice property when it comes to (2): the quaterly release cycle, and
> the independence from the NetBSD release branches.
>
> The trust anchors are not really related to any NetBSD branches, so having
> a global set in -current and always making sure that any changes to it
> get propagated immediately to all branches is doable but seems a bit like
> wasted work. And a typical thing that users do is: grab the latest official
> release (currently that would be the quite ancient 9.3). If the installer
> offers and on request installs the historic set of trust anchors from
> that release time, the user might miss quite a few changes. If instead
> it used something pkgsrc-ish they would get a maximal 3 month outdated
> version.
>
> So using something from pkgsrc, somehow treated specially, and put in
> a constant place (or: published with a constant URL) in every quaterly
> release would be nice for installations with network access and for (2)
> later (automatic) updates.
>
> The special handling does not have to happen inside pkgsrc at all - we
> could have a script that unpacks the amd64 mozilla root certs binary
> pkg once a new version has been uploaded (or the quaterly symlink switched)
> and put that data in an arbitrary format (that is understood by sysinst
> and the [not yet existing] auto-update script) at the fixed URL.
>
> In summary I'd be happy to rely on pkgsrc for this, but I don't think
> we need pkgsrc to make any changes.

We currently have two packages:
- mozilla-rootcerts, which provides certificates in $PREFIX, and a
mozilla-rootcerts script for processing and installed into a format
for openssl.
- mozilla-rootcerts-openssl which is the processed data from
mozilla-rootcerts, installed into .../etc/openssl/certs, which for
native openssl is in /etc

I think we have three stages:
1) TNF making bundled trust-anchor data available - format, building & updating
2) getting the bundled data onto machines and keeping it updated
3) processing the data into /etc/openssl/certs

I think using pkgsrc for 1) is likely to be the best approach, whether
it's consumed as packages, or just downloaded and extracted by some
other means.

For 2), If it's copied and stored on machines as actual packages, it
provides the option of making the update procedure "pkgin install
{whateverwecallit}" (we still need to plumb in for sysinst)

For 3) we could mirror what we have now (which is a
mozilla-rootcerts-openssl package), or have mozilla-rootcerts be what
we bundle, and then have a script which takes it and effectively puts
the ~same data into /etc/openssl/certs, but can check against a config
file which can be extended to allow users to merge in extra
certificates, or exclude some, or even disable that part of the
process

Again, all of this is focussed on getting a good experience for a user
who has selected the default trust-anchors option, but trying to leave
hooks for people who might want to use part of the infrastructure but
tailored their own way.

Another unmentioned local elephant is installations which do not use
sysinst (though I'm happy to suggest we specifically exclude those for
the first pass).

David