Michael-John Turner <mj%mjturner.net@localhost> writes:
> What is the convention for depending on security/ca-certificates for
> applications that need to connect via TLS? Searching the pkgsrc tree I
> don't see any packages that do so.
This is slightly messy and there isn't 100% consensus.
- NetBSD (base) chooses not to ship a set of trust anchors configured
into openssl. That's perhaps a decision that could be revisited,
but that's not a pkgsrc issue.
- we have security/mozilla-rootcerts to install the mozilla set but
not configure it and security/mozilla-rootcerts-openssl to configure
it into openssl
- The entire public CA world is conceptually messy. There are lots of
CAs and surely some of those are not trustworthy, but end up in the
mozilla set anyway. And there are CAs many users would like to
trust (e.g. US DoD) but which are not in the mozilla set (properly,
because they don't meet mozilla's rules).
- firefox carries its own set of CAs and uses those in lieu of
system-configure trust anchors. That's not directly related to your
problem, but an interesting data point. However, I think in general
a program (that isn't so monstrous that it gets to be its own thing)
is a bad thing.
> Background: I've just imported the Gitea CLI into wip (wip/gitea-tea) and
> it works fine, but without ca-certificates installed, TLS connections fail
> because the certificate chain isn't trusted, etc. As I'm guessing most
> users will be connecting via TLS, I added a dependency on ca-certificates,
> but then I see other packages don't do that...
One view is that the admin has failed to configure the set of trust
anchors that they want to trust, and that this isn't bug in your
package, but a feature that CAs that the admin hasn't approved aren't
being used. That's more or less how I see it.
I missed the addition of ca-certificates (which doesn't mean anything;
just pointing that out). A few comments from glancing at it:
- I view it as irregular for the package to configure certificates
just from being installed. (mozilla-rootcerts-openssl does this,
but that is its *sole purpose*.)
- DESCR talks about the "system certificate store", but it is unclear
if that really means "openssl", and if it ends up being pkgsrc
openssl on systems with pkgsrc openssl vs base openssl.
- I am not clear on how ca-certificates interacts or not with other
TLS implementations.
- I don't understand how and why this is different from
mozilla-rootcerts and mozilla-rootcerts-openssl
Having read all that, I think that packages absolutely must not depend
on ca-certificates, because then installing some random package
indirectly causes a change in systemwide security settings. We more or
less came to this conclusion about mozilla-rootcerts-openssl.
Your package is not really special, compared to a vast number of others
that make TLS connections, e.g. wget.
This is all difficult, because there are two conflicting schools of
thought:
it is an important security property that only trust anchors approved
by the sysadmin are used in certificate validation. In this view,
"working" means foremost that the security policy is followed, which
means that certificates being found to be invalid is correct behavior
vs
If a certificate that somebody else might think is valid is not
accepted, that counts as "not working" and is something to be fixed.
pkgsrc has more or less taken the view that choice of trust anchors is
up to the base system config and sysadmin decisions, and pretty clearly
taken the view that it is not up to individual packages to change these
decisions, although mozilla-rootcerts-openssl is provided as a tool for
admins to make that policy choice.
I suggest reading security/mozilla-rootcerts{,-openssl}/DESCR.
Attachment:
signature.asc
Description: PGP signature