From 01645b749376b7026276112d69d5b9c22b000ee4 Mon Sep 17 00:00:00 2001 From: Ruben Kerkhof Date: Wed, 15 Jan 2014 21:31:11 +0400 Subject: [PATCH] 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 Signed-off-by: Ruben Kerkhof Signed-off-by: Junio C Hamano --- git-send-email.perl | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) 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 "") {