From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [PATCHES] profiles: Produce a single-file CA certificate bundle Date: Tue, 03 Mar 2015 21:27:55 +0100 Message-ID: <87twy1su5w.fsf@gnu.org> References: <87r3u7di49.fsf@netris.org> <20150204123652.GA21908@debian.eduroam.u-bordeaux.fr> <87wq3jah2w.fsf@netris.org> <20150215091632.GA9692@debian> <87sie79km0.fsf@netris.org> <87mw441fdp.fsf@gnu.org> <87sidvhx0t.fsf@netris.org> <87zj7v2gmf.fsf_-_@gnu.org> <87fv9medxv.fsf_-_@netris.org> <87sidmmeth.fsf@gnu.org> <20150303125508.GA8991@debian.math.u-bordeaux1.fr> 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]:53768) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YStQB-0007XT-P5 for guix-devel@gnu.org; Tue, 03 Mar 2015 15:28:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YStQ6-0004A0-PW for guix-devel@gnu.org; Tue, 03 Mar 2015 15:28:03 -0500 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58152) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YStQ6-00049w-M9 for guix-devel@gnu.org; Tue, 03 Mar 2015 15:27:58 -0500 In-Reply-To: <20150303125508.GA8991@debian.math.u-bordeaux1.fr> (Andreas Enge's message of "Tue, 3 Mar 2015 13:55:08 +0100") 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-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Andreas Enge Cc: guix-devel@gnu.org Andreas Enge skribis: > privat@debian:/tmp/openssl-1.0.2$ find -type f -exec grep -H SSL_CERT_FIL= E {} \; > ./crypto/cryptlib.h:# define X509_CERT_FILE_EVP "SSL_CERT_FILE" Indeed, I stand corrected. And Lynx does fiddle with it, but only when built with GnuTLS: #ifdef USE_GNUTLS_INCL if ((certfile =3D LYGetEnv("SSL_CERT_FILE")) !=3D NULL) { > So I think it is used and our search path is fine. There=E2=80=99s still the problem that none of these is a search path, thou= gh it works OK for the recommendation that=E2=80=99s printed when installing in a profile. So I=E2=80=99ve pushed this as commit da69977 in =E2=80=98core-updates=E2= =80=99, but we=E2=80=99ll have to extend =E2=80=98search-path-specification=E2=80=99 to describe things li= ke that that are not search paths. Thanks, Ludo=E2=80=99.