Re: GnuTLS and the “trust store”

[Ludovic Courtès]

ng0 <address@hidden> skribis:

> Ludovic Courtès <address@hidden> writes:
>
>> Hello!
>>
>> Marius Bakke <address@hidden> skribis:
>>
>>> Marius Bakke <address@hidden> writes:
>>>
>>>> ng0 <address@hidden> 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.

Not an option: we use GnuTLS anytime there’s a choice (which also avoids
licensing issues with the OpenSSL license).

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

What is “these issues with cURL”?  It builds fine, and it’s perfectly
usable as long as /etc/ssl/certs is populated.

>>          ;; 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?

Good question, I don’t know!  Perhaps we can revisit this.

Thanks,
Ludo’.