Some packages depend on nss-certs, some bundle it.

  • Open
  • quality assurance status badge
Details
3 participants
  • Hartmut Goebel
  • Liliana Marie Prikler
  • Maxime Devos
Owner
unassigned
Submitted by
Maxime Devos
Severity
normal
M
M
Maxime Devos wrote on 20 Apr 2022 17:22
(address . bug-guix@gnu.org)
2e58ada4430ad222c4bc392971edb014c5f10440.camel@telenet.be
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:

Toggle quote (6 lines)
> (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,

Greetings,
Maxime.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYmAlTRccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7jJzAP48lbafYOoc3moZJ4UAQmu9h3e7
Fr4Sfh0hHW04VTyzIwD/ZjyenrNRBsUDeYAQ7yxogchjQpo53f4vA3nHwnTkbAI=
=TpFj
-----END PGP SIGNATURE-----


L
L
Liliana Marie Prikler wrote on 22 Apr 2022 09:17
47c8a97f7d76b08a4164829861a6fc74ac49a104.camel@ist.tugraz.at
Am Mittwoch, dem 20.04.2022 um 17:22 +0200 schrieb Maxime Devos:
Toggle quote (20 lines)
> 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: ...
This is only if you update all of them at once. An update to any one
of them might go to staging instead, which for the record I don't see
merged too often in recent times. Also, with the exception of our
snowflake static linkers Rust and Go, we should be able to graft them
on master.

Toggle quote (7 lines)
> 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?
Point taken, I think these might just be different programming language
implementation that essentially store the same certificate in a known
location and then refer to it. Which Guix can already do by specifying
SSL_CERT_DIR or SSL_CERT_FILE in a wrapper script.
Toggle quote (4 lines)
>  * Lots of rebuilds to update things.
>  * (relatively minir) Allowing overriding the certificates trusted
> with
>    $SSL_CERT_DIR / $SSL_CERT_FILE would be nice.
I don't think SSL_CERT_DIR and SSL_CERT_FILE customization is useful in
all apps however. I think there is a legitimate concern, that users
could be tricked into downloading a malicious certificate chain and
then running their instant messaging app with that, enabling a man in
the middle attack. Again, Guix could solve this by hardcoding
SSL_CERT_*, but...

Toggle quote (1 lines)
> Also relevant to the third point: some packages depend on nss-certs.
We'd be increasing this number if instead of language-specific certifi
packages, we consolidated them into nss-certs. On the other hand, we
would be reducing the number of dependents in libraries that don't need
to hardcode certs for security reasons, so perhaps life will become
easier at some point.

Also, w.r.t. updating nss-certs, since we do have grafts, security
updates should not be a concern in my opinion. Making sure that all
our security-critical instant messaging applications use our trusted
bundle rather than their own very curated set is of higher priority in
my opinion.

Toggle quote (11 lines)
> 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?
From a library/app developer's point of view, you can't rely on the
system certificate store if your system's vendor starts with M, ends
with t and has 7 letters in between. I'm not sure how missing erlang-
certif would impact building any of its packages, but perhaps they
found a way to break builds if some certificate is missing.

Toggle quote (5 lines)
> 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.
Sure. In the meantime, however, I'd suggest mocking them by having
them simply return nss-certs or whatever else we have for a trusted
certificate bundle.

Toggle quote (2 lines)
>  * likewise, forbid new packages from being included as-is if they
> depend on a certifi package or nss-certs.
See above.

Toggle quote (3 lines)
>  * Look into removing the certifi packages from the inputs of
> packages, submitting patches to upstream for using $SSL_CERT_... /
> /etc/ssl/certs ... as appropriate.
That I agree with.


Cheers
H
H
Hartmut Goebel wrote on 25 May 2022 09:26
Re: bug#55043: Some packages depend on nss-certs, some bundle it.
59b9644f-d5b4-3e85-a4a5-c44c1b204983@crazy-compilers.com
Am 20.04.22 um 17:22 schrieb Maxime Devos:
Toggle quote (8 lines)
>> (from Hartmut Goebel, athttps://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?

This argument is just about keeping the actual content of a package
aligned with the content of the official release. This is a is less
impotent argument then what I wrote in

Toggle quote (4 lines)
> All these contain a copy of the/a CA
> bundle — which is the idea of these packages: „useful for systems that
> do not have CA bundles“.

Anyhow: Your proposal is to make upstream packages get rid of these
bundles. Will this being quite some work.

An alternative approach could be to patch these packages, much like
Liliana suggested („mock“).

--
Regards
Hartmut Goebel

| Hartmut Goebel |h.goebel@crazy-compilers.com |
|www.crazy-compilers.com | compilers which you thought are impossible |
Attachment: file
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 55043@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 55043
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch