Re: GnuTLS and the “trust store”

[ng0 <ng0@libertad.pw>]

Ludovic Courtès <ludo@gnu.org> writes:

> Hello!
>
> Marius Bakke <mbakke@fastmail.com> skribis:
>
>> Marius Bakke <mbakke@fastmail.com> writes:
>>
>>> ng0 <ng0@libertad.pw> writes:
>>>
>>>> * gnu/packages/curl.scm (curl)[arguments]: Add "--with-ca-bundle" configure flag.
>
> [...]
>
>> I realized shortly after posting why this wasn't done already. Curl has
>> 1403 dependent packages, which would apply for "nss-certs" as well if
>> that is added as input. Obviously we want to be able to update TLS
>> certificates quickly without rebuilding ~1/4 of the tree.
>
> Indeed.  It’s a situation where we do not want to have a static binding
> between cURL and nss-certs; instead, they should be composed
> dynamically, along the lines of what we already recommend at:

Okay, so my proposed gnURL patch should not be applied at
all. Reading the old threads I'm starting to understand the
situation, but not completely.

>   https://www.gnu.org/software/guix/manual/html_node/X_002e509-Certificates.html
>
> cURL depends on GnuTLS, and GnuTLS doesn’t honor an environment variable
> like ‘SSL_CERT_DIR’.  Its recipe has this comment:

The 3rd option in 2015, subject: [PATCH] gnu: gnutls: Configure
location of system-wide trust store, was to use openssl. Now
we have libressl, so why not try and give that a try in the
future when we (that is, the people with commit access) have
rebuild everything with libressl and it turns out alright?

I'm trying to understand the problem here, the problem why
packages like darcs, pbpst, and others are just sitting, waiting
for months because of issues with cURL. There's a problem, and
I'd like to fix (and understand) it.
Do I have to fix the curl dependent applications? Doesn't sound
like a solution for me which would scale.

>          ;; GnuTLS doesn't consult any environment variables to specify
>          ;; the location of the system-wide trust store.  Instead it has a
>          ;; configure-time option.  Unless specified, its configure script
>          ;; attempts to auto-detect the location by looking for common
>          ;; places in the file system, none of which are present in our
>          ;; chroot build environment.  If not found, then no default trust
>          ;; store is used, so each program has to provide its own
>          ;; fallback, and users have to configure each program
>          ;; independently.  This seems suboptimal.
>          "--with-default-trust-store-dir=/etc/ssl/certs"
>
> Original discussion:
>
>   https://lists.gnu.org/archive/html/guix-devel/2014-02/msg00245.html

I've read some of the threads connected to this one after I
learned about the subject. It usually helps when the subject is
added so I can search locally.
What happened to the p11-kit Andreas mentioned back in 2014 or
2015?

> Ludo’.
>

-- 
♥Ⓐ  ng0
PGP keys and more: https://n0is.noblogs.org/ http://ng0.chaosnet.org