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