On 15 jan. 2014, at 22:30, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Ruben Kerkhof <ruben@xxxxxxxxxxxxxxxx> writes:
>
>>> ... because? Is it because the cert_path on your platform is
>>> different from /etc/ssl/certs? What platform was this anyway?
>>
>> This is Fedora rawhide, git-1.8.5.2-1.fc21.x86_64, perl-IO-Socket-SSL-1.962-1.fc21.noarch
>>>
>>> I see in the original discussion in your bugzilla entry that
>>> "/etc/ssl/certs/" _is_ your ssl cert directory, but I wonder why
>>> then this part of the existing codepath does not work for you:
>>
>> Actually, it's not a directory but a symlink to a directory:
>>
>> [ruben@vm ~]$ ls -l /etc/ssl/certs
>> lrwxrwxrwx. 1 root root 16 Jan 11 12:04 /etc/ssl/certs -> ../pki/tls/certs
>>
>> Just to rule that out I set smtpsslcertpath = /etc/pki/tls/certs,
>> but that doesn't work either.
>
> Yeah, I suspect as much, as "-d" test would dereference symlinks and
> would see /etc/ssl/certs is a symlink pointing at a directory.
>
>> ... I posted the patch to Fedora's bugzilla, since this was
>> biting me on Fedora, and Igor took the liberty to forward it. Not
>> that I mind of course, but please don't take this patch as a
>> proper fix. I don't pretend to fully understand the code and the
>> implications, much less the impact on other platforms.
>
> That is fine, and thanks for starting discussion for a proper fix
> (the "thanks" go to both of you).
>
>>> Also, if the above observation is correct, i.e. we are calling
>>> IO::Socket::SSL with SSL_ca_path set to a correct directory but
>>> somehow your platform is misbehaving and not detecting it as a
>>> proper SSL_ca_path, then it could be argued that the code before
>>> this patch catered people on platforms with one class of breakage,
>>> namely "IO::Socket::SSL does not work with default configuration
>>> without SSL_ca_file nor SSL_ca_path", and the code with this patch
>>> caters people on platforms with another class of breakage, namely
>>> "IO::Socket::SSL does not work when told with SSL_ca_path where the
>>> certificate directory is" (or it could be "/etc/ssl/certs is a
>>> directory that ought to be usable as SSL_ca_path, but it lacks
>>> necessary hash symlinks"). Sort of like robbing Peter to pay Paul,
>>> which is not very nice in principle.
>>
>> I suspect that's exactly the case,...
>
> Actually, there is another possibility. Perhaps on your system,
> even though the current code thinks /etc/ssl/certs/ is usable as
> SSL_ca_path, the directory is not meant to be usable as such, and
> the default OpenSSL uses the equivalent of SSL_ca_file and uses the
> single certificate bundle file without consulting other stuff in the
> directory.
>
> And that is not a broken installation at all, which is sort of
> consistent with your observation here:
>
>> ...
>> As a last check, I set smtpsslcertpath = /etc/pki/tls/cert.pem in
>> ~/.gitconfig and git-send-email works fine now.
>
> Which would mean that the existing code, by blindly defaulting to
> /etc/ssl/certs/ and misdiagnosing that the directory is meant to be
> used as SSL_ca_path, breaks a set-up that otherwise _should_ work.
Exactly. IO::Socket::SSL calls Net::SSLeay::CTX_load_verify_locations( $ctx, $arg_hash->{SSL_ca_file} || '',$arg_hash->{SSL_ca_path} || ''),
which in turn calls OpenSSL's SSL_CTX_load_verify_locations
According to the comments at http://www.openssl.org/docs/ssl/SSL_CTX_load_verify_locations.html, the CApath should be a directory with hashes pointing to
to certs, which is not the case in Fedora.
>
> I see that the original change that introduced the defaulting to
> /etc/ssl/certs/, which is 35035bbf (send-email: be explicit with SSL
> certificate verification, 2013-07-18), primarily wanted to avoid
> letting Net::SMTP::SSL defaulting to no verification and causing it
> to emit warnings of the use of the insecure default. And I think
> the same outcome will result with your patch. By default, we still
> insist on using SSL_VERIFY_PEER(), not SSL_VERIFY_NONE(), which
> would avoid defaulting to insecure communication and triggering the
> warning. The way to disable the security by setting ssl_cert_path
> to an empty string is unchanged.
>
> Ram (who did 35035bbf), with the patch from Ruben in the thread, do
> you get either the warning or SSL failure? Conceptually, the
> resulting code is much better, I think, without blindly defaulting
> /etc/ssl/certs and instead of relying on the underlying platform
> just working out of the box with its own default, and I would be
> happy if we can apply the change without regression to existing
> users.
/etc/pki/tls/cert.pem is a symlink to the Mozilla CA bundle,
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem, which as far as I can tell is the one that should be used for this distro.
Kind regards,
Ruben--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html