diff options
author | Ruben Kerkhof <ruben@rubenkerkhof.com> | 2014-01-15 21:31:11 +0400 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2014-01-17 02:34:51 +0400 |
commit | 01645b749376b7026276112d69d5b9c22b000ee4 (patch) | |
tree | 0a55f89920617069899be4154b06b11c5f1b7d4a /git-send-email.perl | |
parent | 4224916ae979204f13db2996d9e32490e0acb90f (diff) |
send-email: /etc/ssl/certs/ directory may not be usable as ca_path
When sending patches on Fedora rawhide with
git-1.8.5.2-1.fc21.x86_64 and perl-IO-Socket-SSL-1.962-1.fc21.noarch,
with the following
[sendemail]
smtpencryption = tls
smtpserver = smtp.gmail.com
smtpuser = ruben@rubenkerkhof.com
smtpserverport = 587
git-send-email fails with:
STARTTLS failed! SSL connect attempt failed with unknown error
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
verify failed at /usr/libexec/git-core/git-send-email line 1236.
The current code detects the presence of /etc/ssl/certs directory
(it actually is a symlink to another directory, but that does not
matter) and uses SSL_ca_path to point at it when initializing the
connection with IO::Socket::SSL or Net::SMTP::SSL. However, on the
said platform, it seems that this directory is not designed to be
used as SSL_ca_path. Using a single file inside that directory
(cert.pem, which is a Mozilla CA bundle) with SSL_ca_file does work,
and also not specifying any SSL_ca_file/SSL_ca_path (and letting the
library use its own default) and asking for peer verification does
work.
By removing the code that blindly defaults $smtp_ssl_cert_path to
"/etc/ssl/certs", we can prevent the codepath that treats any
directory specified with that variable as usable for SSL_ca_path
from incorrectly triggering.
This change could introduce a regression for people on a platform
whose certificate directory is /etc/ssl/certs but its IO::Socket:SSL
somehow fails to use it as SSL_ca_path without being told. Using
/etc/ssl/certs directory as SSL_ca_path by default like the current
code does would have been hiding such a broken installation without
its user needing to do anything. These users can still work around
such a platform bug by setting the configuration variable explicitly
to point at /etc/ssl/certs.
This change should not negate what 35035bbf (send-email: be explicit
with SSL certificate verification, 2013-07-18), which was the
original change that introduced the defaulting to /etc/ssl/certs/,
attempted to do, which is to make sure we do not communicate over
insecure connection by default, triggering warning from the library.
Cf. https://bugzilla.redhat.com/show_bug.cgi?id=1043194
Tested-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
Signed-off-by: Ruben Kerkhof <ruben@rubenkerkhof.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'git-send-email.perl')
-rwxr-xr-x | git-send-email.perl | 3 |
1 files changed, 2 insertions, 1 deletions
diff --git a/git-send-email.perl b/git-send-email.perl index 3782c3b0cb4..689944f71bf 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -1095,7 +1095,8 @@ sub ssl_verify_params { } if (!defined $smtp_ssl_cert_path) { - $smtp_ssl_cert_path = "/etc/ssl/certs"; + # use the OpenSSL defaults + return (SSL_verify_mode => SSL_VERIFY_PEER()); } if ($smtp_ssl_cert_path eq "") { |