From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andreas Enge <andreas@enge.fr>
Subject: Re: [PATCHES] profiles: Produce a single-file CA certificate bundle
Date: Tue, 3 Mar 2015 13:55:08 +0100
Message-ID: <20150303125508.GA8991@debian.math.u-bordeaux1.fr>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Return-path: <guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:4830:134:3::10]:56968)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <andreas@enge.fr>) id 1YSmM1-0002My-Qb
	for guix-devel@gnu.org; Tue, 03 Mar 2015 07:55:18 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <andreas@enge.fr>) id 1YSmM0-0002e5-PH
	for guix-devel@gnu.org; Tue, 03 Mar 2015 07:55:17 -0500
Content-Disposition: inline
In-Reply-To: <87sidmmeth.fsf@gnu.org>
List-Id: "Development of GNU Guix and the GNU System distribution."
	<guix-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/guix-devel>,
	<mailto:guix-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/guix-devel>
List-Post: <mailto:guix-devel@gnu.org>
List-Help: <mailto:guix-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/guix-devel>,
	<mailto:guix-devel-request@gnu.org?subject=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: Ludovic =?iso-8859-15?Q?Court=E8s?= <ludo@gnu.org>
Cc: guix-devel@gnu.org

On Tue, Mar 03, 2015 at 01:43:38PM +0100, Ludovic Courtès wrote:
> I just checked the source and OpenSSL itself does not use SSL_CERT_FILE
> nor SSL_CERT_DIR at all.  Lynx does use SSL_CERT_FILE, but that’s really
> in Lynx, not in libssl.  So I don’t think there should be a search path
> specification for OpenSSL.  This is unfortunate, but it looks like we
> can’t do much.

I just did a "strings" and "grep" on the binaries and libs. SSL_CERT_DIR
appears in bin/c_rehash and lib/libcrypto.so, and SSL_CERT_FILE also appears
in the latter.

In the source code,
$ find -type f -exec grep -H SSL_CERT_DIR {} \;
yields:

./crypto/cryptlib.h:# define X509_CERT_DIR_EVP        "SSL_CERT_DIR"
./tools/c_rehash.in:} elsif($ENV{SSL_CERT_DIR}) {
./tools/c_rehash.in:    @dirlist = split /$path_delim/, $ENV{SSL_CERT_DIR};
./tools/c_rehash:} elsif($ENV{SSL_CERT_DIR}) {
./tools/c_rehash:       @dirlist = split /$path_delim/, $ENV{SSL_CERT_DIR};
./doc/apps/c_rehash.pod:processed in turn. If not, then the B<SSL_CERT_DIR> environment variable
./doc/apps/c_rehash.pod:=item B<SSL_CERT_DIR>

and
$ find -type f -exec grep -H SSL_CERT_FILE {} \;

privat@debian:/tmp/openssl-1.0.2$ find -type f -exec grep -H SSL_CERT_FILE {} \;
./crypto/cryptlib.h:# define X509_CERT_FILE_EVP       "SSL_CERT_FILE"

So I think it is used and our search path is fine.

By the way, in the next core-updates round, we may wish to erase the empty
directories ssl/certs and ssl/private.

Andreas