From: Maxime Devos <maximedevos@telenet.be>
To: 55043@debbugs.gnu.org
Cc: hartmut goebel <h.goebel@crazy-compilers.com>
Subject: bug#55043: Some packages depend on nss-certs, some bundle it.
Date: Wed, 20 Apr 2022 17:22:53 +0200 [thread overview]
Message-ID: <2e58ada4430ad222c4bc392971edb014c5f10440.camel@telenet.be> (raw)
[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]
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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
next reply other threads:[~2022-04-20 15:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-20 15:22 Maxime Devos [this message]
2022-04-22 7:17 ` bug#55043: Some packages depend on nss-certs, some bundle it Liliana Marie Prikler
2022-05-25 7:26 ` Hartmut Goebel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2e58ada4430ad222c4bc392971edb014c5f10440.camel@telenet.be \
--to=maximedevos@telenet.be \
--cc=55043@debbugs.gnu.org \
--cc=h.goebel@crazy-compilers.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.