[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.
signature.asc
Description: This is a digitally signed message part
- bug#55043: Some packages depend on nss-certs, some bundle it.,
Maxime Devos <=