summaryrefslogtreecommitdiff
path: root/git-send-email.perl
diff options
context:
space:
mode:
authorRuben Kerkhof <ruben@rubenkerkhof.com>2014-01-15 21:31:11 +0400
committerJunio C Hamano <gitster@pobox.com>2014-01-16 14:34:51 -0800
commit01645b749376b7026276112d69d5b9c22b000ee4 (patch)
tree0a55f89920617069899be4154b06b11c5f1b7d4a /git-send-email.perl
parent4224916ae979204f13db2996d9e32490e0acb90f (diff)
downloadgit-01645b749376b7026276112d69d5b9c22b000ee4.tar.gz
send-email: /etc/ssl/certs/ directory may not be usable as ca_pathrk/send-email-ssl-cert
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-xgit-send-email.perl3
1 files changed, 2 insertions, 1 deletions
diff --git a/git-send-email.perl b/git-send-email.perl
index 3782c3b0cb..689944f71b 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 "") {