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

Merge branch 'mt/send-email-cover-to-cc'

2014-06-20T20:12:20Z

* mt/send-email-cover-to-cc: t9001: avoid non-portable '\n' with sed test/send-email: to-cover, cc-cover tests git-send-email: two new options: to-cover, cc-cover

git-send-email: two new options: to-cover, cc-cover

2014-04-29T18:27:41Z

Allow extracting To/Cc addresses from the first patch (typically the cover letter), and use them as To/Cc addresses of the remainder of the series. Signed-off-by: Michael S. Tsirkin Signed-off-by: Junio C Hamano

send-email: windows drive prefix (e.g. C:) appears only at the beginning

2014-04-23T16:37:38Z

Tighten the regexp used in the "file_name_is_absolute" replacement used on msys to declare that only "[a-zA-Z]:" that appear at the very beginning is a path with a drive-prefix. Signed-off-by: Junio C Hamano

send-email: recognize absolute path on Windows

2014-04-16T18:51:16Z

On Windows, absolute paths might start with a DOS drive prefix, which these two checks failed to recognize. Unfortunately, we cannot simply use the file_name_is_absolute helper in File::Spec::Functions, because Git for Windows has an MSYS-based Perl, where this helper doesn't grok DOS drive-prefixes. So let's manually check for these in that case, and fall back to the File::Spec-helper on other platforms (e.g Win32 with native Perl) Signed-off-by: Erik Faye-Lund Signed-off-by: Junio C Hamano

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