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

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

Hi,

There are some packages bundling CA certificates:

* erlang-certifi (not yet, see https://issues.guix.gnu.org/54796#3)

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?

python-certifi / perl-mozilla-ca / rust-webpki-roots / ...

up to date. Security problems!

$SSL_CERT_DIR / $SSL_CERT_FILE instead?

$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:

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

you elaborate?

Proposal:

appears to be keeping them up-to-date and for security it is important

for them to be up to date.

a certifi package or nss-certs.

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.

Am Mittwoch, dem 20.04.2022 um 17:22 +0200 schrieb Maxime Devos:

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.

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.

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...

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.

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.

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.

See above.

That I agree with.

Cheers

Am 20.04.22 um 17:22 schrieb Maxime Devos:

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

https://issues.guix.gnu.org/54796#52:

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 |