pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Depending on security/ca-certificates?

Michael-John Turner <> 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

  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


  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

Home | Main Index | Thread Index | Old Index