Re: mozilla rootcerts in base

[Greg Troxel <gdt%lexort.com@localhost>]

pin <voidpin%protonmail.com@localhost> writes:

> I've noticed riastradh@ has added mozilla-rootcerts to base.
> So, I've rm -r /etc/openssl and upgraded the base system.
>
> ~ > uname -a
> NetBSD mybox 10.99.7 NetBSD 10.99.7 (GENERIC) #0: Mon Aug 28 11:12:42 UTC 2023  mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/amd64/compile/GENERIC amd64
>
> I can see the rootcerts are installed
> ~ > ls /etc/openssl/
> drwxr-xr-x root wheel 9.0 KB Tue Aug 29 09:56:03 2023  certs
> .r--r--r-- root wheel 373 B  Mon Aug 28 13:12:42 2023  certs.conf
> drwxr-xr-x root wheel 512 B  Mon Aug 28 13:12:42 2023  misc
> drwx------ root wheel 512 B  Mon Aug 28 13:12:42 2023  private
>
> So, I thought I could simply remove the mozilla-rootcerts package but, it's not that simple :(
>
> ~ > pkgin rm mozilla-rootcerts
> 23 packages to delete:
>   qt5-qtwebsockets-5.15.10 qt5-qtwebchannel-5.15.10 qt5-qtmultimedia-5.15.10 qt5-qtdeclarative-5.15.10nb1 qt5-qtx11extras-5.15.10 simp-3.4.0 featherpad-1.4.1 qt5-qtsensors-5.15.10
>   qt5-qtxmlpatterns-5.15.10 qt5-qtserialport-5.15.10 qt5-qtlocation-5.15.10 qt5ct-1.7nb3 qt5-qtsvg-5.15.10 qt5-qttools-5.15.10 xpdf-4.04nb8 qt5-qtbase-5.15.10 gtk3+-3.24.38nb1
>   firefox-116.0.3 ffmpeg6-6.0nb1 libcups-2.4.6nb1 gnutls-3.8.1 p11-kit-0.25.0 mozilla-rootcerts-1.0.20230720
>
> proceed ? [Y/n] n

Note that lots of these are indirect dependencies, which are not
actually related, and that looking at pkg_info is more useful.  On my
system that's

  python27-2.7.18nb11
  p11-kit-0.25.0
  gnutls-3.8.1
  qca2-qt5-2.3.5nb4

even though the pkgin incantation above wants to delete 199 packages on
my system.

> Shouldn't pkgsrc know about the change and allow the removable of
> mozilla-rootcerts without removing all packages depending on it?

Today, not at all -- that's quite a leap.  There are two completely
separate packages, and this is the other one :-)

The mozilla-rootcerts package installs mozilla's list of trust anchors
(a pile of CA certs) into share/mozilla-rootcerts.  See the DESCR which
has been carefully worded by a pedant.

Some programs want to have this data available for whatever reasons, and
that's fine.  It seems there are trust anchors for S/MIME vs https, as
someone said upthread.

There is a second package mozilla-rootcerts-openssl which puts those CA
certs into openssl's cert dir.  This package uses mozilla-rootcerts as a
build tool only, and I just fixed the DESCR to say this.  

From the base viewpoint, mozilla-rootcerts-openssl being installed looks
like "sysadmin has configured trust anchors".  This is not a confused
view; that is actually what happened.  People need to remove this
package before using the base certctl and I am not sure that is 100%
worked out.  But certctl should now refuse to write the certs dir with
mozilla-rootcerts-openssl installed.

We of course need to be mindful that pkgsrc runs on NetBSD 8, 9 and 10,
and 20 other systems, and that we should have a coherent approach to
using base trust anchors.

Summarizing/restarting what others have mentioned, there are multiple
questions:

  - whether what base installs is usable as a substitute for things
    that expect the mozilla-rootcerts package

  - if so, whether we should have a builtin.mk

  - if there is a builtin.mk, then security updates in pkgsrc are not
    partially about base updates, in a way that tends more to base than
    pkgsrc used to be.  That might be ok, but it is far from obvious
    that it is the right approach.

  - if having a builtin.mk likely requires a lot of per-package changes
    to use variables for paths

The idea that somehow pkgsrc should have deep knowledge about the
transition and somehow pivot out the package and replace with builtin
automatically on an installation does not make sense to me at all.  That
is way beyond the level of complexity that we deal with; the standard
path is just having new bulk builds build things the new way.

To make this work at all, base would have to have the same forms that
these programs are expecting.  That question is just being asked and is
unclear to me.

So if we did decided to go the builtin.mk route and what base installs
is sufficient and used, then doing a pbulk update run or 'make replace'
would result in e.g. gnutls using the base config instead and not having
a dependency.  When all the packages have been updated then
mozilla-rootcerts would be eligible for `pkgin ar`.  This is how it has
always been in the past for a new builtin.mk.

I see no problems arising from mozilla-rootcerts continuing to be
installed and used by gnutls etc. as it is now.   So "base updated but
mozilla-rootcerts package is still present" I see as not needing fixing,
but perhaps a future minor optimization.

Certainly those questions are reasonable to discuss, but mozilla
rootcerts are just hitting NetBSD-current, and therefore has to be
viewed as not yet baked.  When it has settled, someone could look into
the various forms of data and whether base provides this, and the update
sequencing/timeliness issue.

I expect some growing pains with this situation.  With 2023Q3 branch
manager hat on, I would like us not to try to change how this works in
pkgsrc before the branch at all.

Except perhaps using NOT_FOR in mozilla-rootcerts-openssl when the build
detects certctl or something.  I'd like to see that proposed/discussed
before it happens, especially because the build-time exclusion doesn't
address the real issue, which is installation of a package previously
built or built for an earlier branch.