ng0 <n...@libertad.pw> skribis: > Ludovic Courtès <l...@gnu.org> writes: > >> Hello! >> >> Marius Bakke <mba...@fastmail.com> skribis: >> >>> Marius Bakke <mba...@fastmail.com> writes: >>> >>>> ng0 <n...@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.
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’.