bug-guix
[Top][All Lists]
Advanced

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

bug#55043: Some packages depend on nss-certs, some bundle it.


From: Maxime Devos
Subject: bug#55043: Some packages depend on nss-certs, some bundle it.
Date: Wed, 20 Apr 2022 17:22:53 +0200
User-agent: Evolution 3.38.3-1

X-Debbugs-CC: Hartmut Goebel <h.goebel@crazy-compilers.com>

Hi,

There are some packages bundling CA certificates:

 * nss-certs / le-certs (this one is not a problem)
 * python-certifi
 * perl-mozilla-ca
 * rust-webpki-roots
 * erlang-certifi (not yet, see <https://issues.guix.gnu.org/54796#3>)
 * go-github-com-certifi-gocertifi

Worse, these packages have many dependencies!

$ guix refresh -l nss-certs le-certs python-certifi perl-mozilla-ca
rust-webpki-roots 
Het bouwen van het volgende 534 pakketten zorgt ervoor dat 1575 afhankelijke 
pakketten opnieuw worden gebouwd: ...

Why is this a problem?

 * I don't think that anybody is actually looking into keeping
   python-certifi / perl-mozilla-ca / rust-webpki-roots / ...
   up to date.  Security problems!
 * Even so, this seems a waste of time to me, why not just use
   $SSL_CERT_DIR / $SSL_CERT_FILE instead?
 * Lots of rebuilds to update things.
 * (relatively minir) Allowing overriding the certificates trusted with
   $SSL_CERT_DIR / $SSL_CERT_FILE would be nice.

Also relevant to the third point: some packages depend on nss-certs.

I've heard an argument in favour of just using the certifi packages
instead of using our own certificates:

> (from Hartmut Goebel, at <https://issues.guix.gnu.org/54796#52>)
> Neither python-certifi nor gocertifi build on nss-cert. Addind some 
> update mechanism into the Guix package is not a good idea IMO: This 
> would make “erlang-certif@2.9.0“ contain different certificates
> than the release 2.9.0, making debugging a hell.

... but I don't follow, it's just a different set of certificates, could
you elaborate? 

Proposal:

 * eventually remove python-certifi, perl-mozilla-ca, ... because nobody
   appears to be keeping them up-to-date and for security it is important
   for them to be up to date.
 
 * likewise, forbid new packages from being included as-is if they depend on
   a certifi package or nss-certs.

 * Look into removing the certifi packages from the inputs of packages,
   submitting patches to upstream for using $SSL_CERT_... / /etc/ssl/certs ...
   as appropriate.

Upstream issues and patches I'm aware of:

 * (python-requests, bug report): https://github.com/psf/requests/issues/2966
 * (rebar3, bug report + patch): https://github.com/erlang/rebar3/issues/2696,
   https://github.com/erlang/otp/pull/5853

Greetings,
Maxime.

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]