From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: GnuTLS and the =?utf-8?Q?=E2=80=9Ctrust_store=E2=80=9D?= Date: Thu, 05 Jan 2017 11:28:54 +0100 Message-ID: <87shoxvlzt.fsf@gnu.org> References: <20170104144655.12321-1-ng0@libertad.pw> <20170104144655.12321-2-ng0@libertad.pw> <874m1ezugu.fsf@kirby.i-did-not-set--mail-host-address--so-tickle-me> <871swizsqv.fsf@kirby.i-did-not-set--mail-host-address--so-tickle-me> <87vatuimnp.fsf_-_@gnu.org> <87h95escjh.fsf@wasp.i-did-not-set--mail-host-address--so-tickle-me> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56083) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cP5I5-0001AI-Ut for guix-devel@gnu.org; Thu, 05 Jan 2017 05:29:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cP5I1-00013z-TJ for guix-devel@gnu.org; Thu, 05 Jan 2017 05:29:01 -0500 In-Reply-To: <87h95escjh.fsf@wasp.i-did-not-set--mail-host-address--so-tickle-me> (ng0@libertad.pw's message of "Wed, 04 Jan 2017 22:09:06 +0000") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: ng0 Cc: guix-devel@gnu.org ng0 skribis: > Ludovic Court=C3=A8s writes: > >> Hello! >> >> Marius Bakke skribis: >> >>> Marius Bakke writes: >>> >>>> ng0 writes: >>>> >>>>> * gnu/packages/curl.scm (curl)[arguments]: Add "--with-ca-bundle" con= figure 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=E2=80=99s 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-Certifica= tes.html >> >> cURL depends on GnuTLS, and GnuTLS doesn=E2=80=99t honor an environment = variable >> like =E2=80=98SSL_CERT_DIR=E2=80=99. 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=E2=80=99s a choice (which also a= voids 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 =E2=80=9Cthese issues with cURL=E2=80=9D? It builds fine, and it= =E2=80=99s 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 scri= pt >> ;; 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 tru= st >> ;; 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=3D/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=E2=80=99t know! Perhaps we can revisit this. Thanks, Ludo=E2=80=99.