[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GnuTLS and the “trust store”

From: Ludovic Courtès
Subject: Re: GnuTLS and the “trust store”
Date: Thu, 05 Jan 2017 11:28:54 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]