Re: mozilla rootcerts in base

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

Taylor R Campbell <riastradh%NetBSD.org@localhost> writes:

>> Date: Tue, 29 Aug 2023 10:52:53 +0200
>> From: Tobias Nygren <tnn%NetBSD.org@localhost>
>> 
>> I think your dependency chains can be mostly traced to p11-kit, which
>> wants to be configured with an explicit path:
>> 
>> CONFIGURE_ARGS+=	--with-trust-paths=${PREFIX}/share/mozilla-rootcerts/cacert.pem
>
> If this is for TLS validation, this should probably be done with
> something like the logic in security/openssl/builtin.mk instead to set
> SSLCERTS, since
>
> (a) that's not where the _configured_ trust anchors live, just where
>     _one set_ of data files exist that configuration should point to;
>     and
>
> (b) where the configured TLS trust anchors live varies from OS to OS,
>     like /etc/openssl/certs on NetBSD, /etc/ssl/certs on FreeBSD,
>     /etc/pki/tls/certs on Fedora, &c.
>
> Of course, it's not quite right for this to be taken from
> security/openssl/builtin.mk because it's about TLS, not OpenSSL
> (despite the confusingly named path in NetBSD for hysterical raisins
> which we are not about to change).

Sure, but we may still wish to have a tls-trust-anchors.mk that asks for this.

> On the other hand, it's not obvious to me that p11-kit is using this
> for TLS validation; if not, perhaps it should be doing something else
> altogether.

Indeed, a lot of usages are not clear, and may be not right.

> (And as a side note, I noticed that mozilla-rootcerts includes a bunch
> of trust anchors designated for S/MIME, not for TLS validation, so
> those shouldn't be put into /etc/openssl/certs...)

Why do you say that?  openssl can be used as a library for things less
than TLS, certainly including pkix validation.  The trust anchor certs
ought to have usage extensions that limit this, and validation calls
should be specificying usage.   After all, this going in is a decision
to drink the pkix koolaid.

Why is the base system setting up for TLS only, vs pkix validation in
general?  TLS is just one specific case.

>> Adding a builtin.mk to the mozilla-rootcerts package that
>> exposes the path to trust store as a pkgsrc variable could be one
>> way to solve this.
>
> I'm not sure that's the right thing either.  There's no
> mozilla-rootcerts _command_ in NetBSD base, and the files aren't
> exposed in quite the same way, so what's in NetBSD base isn't exactly
> a builtin version of the mozilla-rootcerts package.

Agreed, but I think we probably should have

  mk/pkix-trust-anchors.mk

which sets variables and then perhaps depends on something.  However, in
the brave new world of "OS configures trust anchors" which we are
arriving in as NetBSD does, this should ~always be the system-configured
set, and never use the mozilla set within pkgsrc.  Except if it's asked
for with a variable probably.

I think we should keep mozilla-rootcerts indefinitely, and allow people
to set cert.conf to load from it instead of the set included in base.
Perhaps that package should omit the install script when built for an OS
that has native management.

We have been mostly talking about openssl because that's what base uses,
but there are multiple programs that can do pkix validation:
  openssl
  [openssl variants]
  gnutls
  gnupg2
  qca2-qt5
  p11-kit (it seems; see file:///usr/pkg/share/gtk-doc/html/p11-kit/trust.html)


The big point that I take away is that there are a number of formats,
perhaps just a symlinks/files method and a bundle method, for this, and
I hope certctl already prepares both, even if openssl only uses one.

(I still don't want to do any of this pre-branch.  I think it's unhealthy
to rush and I don't want to deal with any more churn/grief than is
already going to happen for unrelated reasons.)