All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Kyle J. McKay" <mackyle@gmail.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	Ruben Kerkhof <ruben@rubenkerkhof.com>,
	Ramkumar Ramachandra <artagnon@gmail.com>,
	Igor Gnatenko <i.gnatenko.brain@gmail.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH] send-email: If the ca path is not specified, use the defaults
Date: Fri, 17 Jan 2014 10:14:47 -0800	[thread overview]
Message-ID: <xmqqlhyexyp4.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <E036CD5E-69B1-4ABD-957B-8E31D410A897@gmail.com> (Kyle J. McKay's message of "Thu, 16 Jan 2014 20:21:32 -0800")

"Kyle J. McKay" <mackyle@gmail.com> writes:

> On my OS X platform depending on which version of OpenSSL I'm using,
> the OPENSSLDIR path would be one of these:
>
>   /System/Library/OpenSSL
>   /opt/local/etc/openssl
>
> And neither of those uses a "certs" directory, they both use a
> "cert.pem" bundle instead:
>
>   $ ls -l /System/Library/OpenSSL
>   total 32
>   lrwxrwxrwx  1 root  wheel    42 cert.pem -> ../../../usr/share/curl/
> curl-ca-bundle.crt
>   drwxr-xr-x  2 root  wheel    68 certs
>   drwxr-xr-x  8 root  wheel   272 misc
>   -rw-r--r--  1 root  wheel  9381 openssl.cnf
>   drwxr-xr-x  2 root  wheel    68 private
>   # the certs directory is empty
>
>   $ ls -l /opt/local/etc/openssl
>   total 32
>   lrwxrwxrwx   1 root  admin    35 cert.pem@ -> ../../share/curl/curl-
> ca-bundle.crt
>   drwxr-xr-x   9 root  admin   306 misc/
>   -rw-r--r--   1 root  admin 10835 openssl.cnf
>
> Notice neither of those refers to /etc/ssl/certs at all.
>
> So the short answer is, yes, hard-coding /etc/ssl/certs as the path on
> OS X is incorrect and if setting /etc/ssl/certs as the path has the
> effect of replacing the default locations the verification will fail.

The current code says "if nothing is specified, let's pretend
/etc/ssl/certs was specified.  Then if it is a directory, use it
with SSL_ca_path, if it is a file, use it with SSL_ca_file, if it
does not exist, do not even attempt verification."

And that "let's pretend" breaks Fedora, where "/etc/ssl/certs" is a
directory but is not meant to be used with SSL_ca_path---we try to
use /etc/ssl/certs with SSL_ca_path and verification fails miserably.

If I am reading the code correctly, if /etc/ssl/certs does not exist
on the filesystem at all, it wouldn't even attempt verification, so
I take your "the verification will fail" to mean that you forgot to
also mention "And on OS X, /etc/ssl/certs directory still exists,
even though OpenSSL does not use it."  If that is the case, then our
current code indeed is broken in exactly the same way for OS X as
for Fedora.

The proposed change in this thread would stop the defaulting
altogether, and still ask verification to the library using its own
default, so I can see how that would make the setting you described
used on OS X work properly.

In short, I agree with you on both counts (the current code is wrong
for OS X, and the proposed change will fix it).  I just want to make
sure that my understanding of the current breakage is in line with
the reality ;-)

Thanks.

  reply	other threads:[~2014-01-17 18:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-15 17:31 [PATCH] send-email: If the ca path is not specified, use the defaults Igor Gnatenko
2014-01-15 19:26 ` Junio C Hamano
     [not found]   ` <7AD1C6ED-6177-415D-B342-D1FEA9F810B4@rubenkerkhof.com>
2014-01-15 21:30     ` Junio C Hamano
2014-01-15 21:50       ` Ruben Kerkhof
2014-01-15 21:50       ` Jonathan Nieder
2014-01-16 23:19         ` Junio C Hamano
2014-01-17  4:21           ` Kyle J. McKay
2014-01-17 18:14             ` Junio C Hamano [this message]
2014-01-17 23:34               ` Kyle J. McKay
2014-01-26 17:17           ` Ramkumar Ramachandra
2014-01-27 16:02             ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqlhyexyp4.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=i.gnatenko.brain@gmail.com \
    --cc=jrnieder@gmail.com \
    --cc=mackyle@gmail.com \
    --cc=ruben@rubenkerkhof.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.