git/git-send-email.perl, branch v2.0.2

Merge branch 'rk/send-email-ssl-cert'

2014-01-27T18:44:34Z

The "if /etc/ssl/certs/ directory exists, explicitly telling the library to use it as SSL_ca_path" blind-defaulting in "git send-email" broke platforms where /etc/ssl/certs/ directory exists, but it cannot used as SSL_ca_path (e.g. Fedora rawhide). Fix it by not specifying any SSL_ca_path/SSL_ca_file but still asking for peer verification in such a case. * rk/send-email-ssl-cert: send-email: /etc/ssl/certs/ directory may not be usable as ca_path

send-email: /etc/ssl/certs/ directory may not be usable as ca_path

2014-01-16T22:34:51Z

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

send-email: set SSL options through IO::Socket::SSL::set_client_defaults

2013-12-04T19:45:32Z

When --smtp-encryption=ssl, we use a Net::SMTP::SSL connection, passing its ->new all the options that would otherwise go to Net::SMTP->new (most options) and IO::Socket::SSL->start_SSL (for the SSL options). However, while Net::SMTP::SSL replaces the underlying socket class with an SSL socket, it does nothing to allow passing options to that socket. So the SSL-relevant options are lost. Fortunately there is an escape hatch: we can directly set the options with IO::Socket::SSL::set_client_defaults. They will then persist within the IO::Socket::SSL module. Signed-off-by: Thomas Rast Signed-off-by: Junio C Hamano

send-email: --smtp-ssl-cert-path takes an argument

2013-12-04T19:45:30Z

35035bb (send-email: be explicit with SSL certificate verification, 2013-07-18) forgot to specify that --smtp-ssl-cert-path takes a string argument. This means that the option could not actually be used as intended. Presumably noone noticed because it's much easier to set it through configs anyway. Add the required "=s". Signed-off-by: Thomas Rast Signed-off-by: Junio C Hamano

send-email: pass Debug to Net::SMTP::SSL::new

2013-12-04T19:45:27Z

We forgot to pass the Debug option through to Net::SMTP::SSL->new -- which is the same as Net::SMTP->new. This meant that with security set to SSL, we would never enable debug output. Pass through the flag. Signed-off-by: Thomas Rast Signed-off-by: Junio C Hamano

send-email: don't call methods on undefined values

2013-09-10T15:49:22Z

If SSL verification is enabled in git send-email, we could attempt to call a method on an undefined value if the verification failed, since $smtp would end up being undef. Look up the error string in a way that will produce a helpful error message and not cause further errors. Signed-off-by: Brian M. Carlson Signed-off-by: Junio C Hamano

Merge branch 'rr/send-email-ssl-verify'

2013-07-22T18:24:17Z

Newer Net::SMTP::SSL module does not want the user programs to use the default behaviour to let server certificate go without verification, so by default enable the verification with a mechanism to turn it off if needed. * rr/send-email-ssl-verify: send-email: be explicit with SSL certificate verification

send-email: be explicit with SSL certificate verification

2013-07-18T23:01:30Z

When initiating an SSL connection without explicitly specifying the SSL certificate verification mode, Net::SMTP::SSL defaults to no verification, but recent versions of the module gives a warning against this use of the default. Enable certificate verification by default, using /etc/ssl/certs as the default path for certificates of certificate authorities. This path can be overriden by the --smtp-ssl-cert-path command line option and the sendemail.smtpSSLCertPath configuration variable. Passing an empty string as the path for CA certificates path disables the SSL certificate verification explicitly, which does not trigger the warning from recent versions of Net::SMTP::SSL. Signed-off-by: Ramkumar Ramachandra Helped-by: Brian M. Carlson Signed-off-by: Junio C Hamano

Merge branch 'bc/send-email-use-port-as-separate-param'

2013-07-15T17:28:50Z

Pass port number as a separate argument when send-email initializes Net::SMTP, instead of as a part of the hostname, i.e. host:port. This allows GSSAPI codepath to match with the hostname given. * bc/send-email-use-port-as-separate-param: send-email: provide port separately from hostname

send-email: provide port separately from hostname

2013-07-05T04:40:37Z

If the SMTP port is provided as part of the hostname to Net::SMTP, it passes the combined string to the SASL provider; this causes GSSAPI authentication to fail since Kerberos does not want the port information. Instead, pass the port as a separate argument as is done for SSL connections. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano