summaryrefslogtreecommitdiff
path: root/git-send-email.perl
AgeCommit message (Collapse)AuthorFilesLines
2014-02-13Merge branch 'rk/send-email-ssl-cert' into maintLibravatar Junio C Hamano1-1/+2
A recent update to "git send-email" broke platforms where /etc/ssl/certs/ directory exists but cannot be used as SSL_ca_path (e.g. Fedora rawhide). * rk/send-email-ssl-cert: send-email: /etc/ssl/certs/ directory may not be usable as ca_path
2014-01-16send-email: /etc/ssl/certs/ directory may not be usable as ca_pathLibravatar Ruben Kerkhof1-1/+2
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>
2013-12-04send-email: set SSL options through IO::Socket::SSL::set_client_defaultsLibravatar Thomas Rast1-2/+5
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 <tr@thomasrast.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-04send-email: --smtp-ssl-cert-path takes an argumentLibravatar Thomas Rast1-1/+1
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 <tr@thomasrast.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-04send-email: pass Debug to Net::SMTP::SSL::newLibravatar Thomas Rast1-0/+1
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 <tr@thomasrast.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-10send-email: don't call methods on undefined valuesLibravatar Brian M. Carlson1-1/+1
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 <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-22Merge branch 'rr/send-email-ssl-verify'Libravatar Junio C Hamano1-3/+38
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
2013-07-18send-email: be explicit with SSL certificate verificationLibravatar Ramkumar Ramachandra1-3/+38
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 <artagnon@gmail.com> Helped-by: Brian M. Carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-15Merge branch 'bc/send-email-use-port-as-separate-param'Libravatar Junio C Hamano1-2/+4
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
2013-07-04send-email: provide port separately from hostnameLibravatar brian m. carlson1-2/+4
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 <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-27Merge branch 'mt/send-email-cc-match-fix'Libravatar Junio C Hamano1-2/+3
Logic used by git-send-email to suppress cc mishandled names that need RFC2047 quoting. * mt/send-email-cc-match-fix: send-email: sanitize author when writing From line send-email: add test for duplicate utf8 name
2013-06-20send-email: sanitize author when writing From lineLibravatar Michael S. Tsirkin1-2/+3
sender is now sanitized, but we didn't sanitize author when checking whether From: line is needed in the message body. As a result git started writing duplicate From: lines when author matched sender and has utf8 characters. Reported-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-14Merge branch 'mt/send-email-cc-match-fix'Libravatar Junio C Hamano1-8/+15
Logic git-send-email used to suppress cc mishandled names like "A U. Thor" <author@example.xz>, where the human readable part needs to be quoted (the user input may not have the double quotes around the name, and comparison was done between quoted and unquoted strings). * mt/send-email-cc-match-fix: test-send-email: test for pre-sanitized self name t/send-email: test suppress-cc=self with non-ascii t/send-email: add test with quoted sender send-email: make --suppress-cc=self sanitize input t/send-email: test suppress-cc=self on cccmd send-email: fix suppress-cc=self on cccmd t/send-email.sh: add test for suppress-cc=self
2013-06-05send-email: make --suppress-cc=self sanitize inputLibravatar Michael S. Tsirkin1-8/+15
--suppress-cc=self fails to filter sender address in many cases where it needs to be sanitized in some way, for example quoted: "A U. Thor" <author@example.com> To fix, make send-email sanitize both sender and the address it is compared against. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-05send-email: fix suppress-cc=self on cccmdLibravatar Michael S. Tsirkin1-1/+1
When cccmd is used, old-style suppress-from filter is applied by the newer suppress-cc=self isn't. Fix this up. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-28send-email: remove warning about unset chainreplytoLibravatar Felipe Contreras1-17/+2
Three years and a half is probably more than enough time to give users the opportunity to configure Git to do what they want. If they haven't changed the configuration by now, this warning message is not going to do anything for them anyway. This effectively reverts commit 528fb08 (prepare send-email for smoother change of --chain-reply-to default). Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07send-email: make annotate configurableLibravatar Felipe Contreras1-3/+4
Some people always do --annotate, lets not force them to always type that. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-05Merge branch 'rr/send-email-perl-critique'Libravatar Junio C Hamano1-8/+10
Update "git send-email" for issues noticed by PerlCritic. * rr/send-email-perl-critique: send-email: use the three-arg form of open in recipients_cmd send-email: drop misleading function prototype send-email: use "return;" not "return undef;" on error codepaths
2013-03-31send-email: use the three-arg form of open in recipients_cmdLibravatar Ramkumar Ramachandra1-1/+1
Perlcritic does not want to see the trailing pipe in the two-args form of open(), i.e. open my $fh, "$cmd \Q$file\E |"; If $cmd were a single-token command name, it would make a lot more sense to use four-or-more-args form "open FILEHANDLE,MODE,CMD,ARGS" to avoid shell from expanding metacharacters in $file, but we do expect multi-word string in $to_cmd and $cc_cmd to be expanded by the shell, so we cannot rewrite it to open my $fh, "-|", $cmd, $file; for extra safety. At least, by using this in the three-arg form: open my $fh, "-|", "$cmd \Q$file\E"; we can silence Perlcritic, even though we do not gain much safety by doing so. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-31send-email: drop misleading function prototypeLibravatar Ramkumar Ramachandra1-4/+6
The subroutine check_file_rev_conflict() is called from two places, both of which expects to pass a single scalar variable and see if that can be interpreted as a pathname or a revision name. It is defined with a function prototype ($) to force a scalar context while evaluating the arguments at the calling site but it does not help the current calling sites. The only effect it has is to hurt future calling sites that may want to build an argument list in an array variable and call it as check_file_rev_confict(@args). Drop the misleading prototype, as Perlcritic suggests. While at it, rename the function to avoid new call sites unaware of this change arising and add a comment clarifying what this function is for. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-31send-email: use "return;" not "return undef;" on error codepathsLibravatar Ramkumar Ramachandra1-3/+3
All the callers of "ask", "extract_valid_address", and "validate_patch" subroutines assign the return values from them to a single scalar: $var = subr(...); and "return undef;" in these subroutine can safely be turned into a simpler "return;". Doing so will also future-proof a new caller that mistakenly does this: @foo = ask(...); if (@foo) { ... we got an answer ... } else { ... we did not ... } Note that we leave "return undef;" in validate_address on purpose, even though Perlcritic may complain. The primary "return" site of the function returns whatever is in the scalar variable $address, so it is pointless to change only the other "return undef;" to "return". The caller must be prepared to see an array with a single undef as the return value from this subroutine anyway. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-27git-send-email: use git credential to obtain passwordLibravatar Michal Nazarewicz1-28/+43
If smtp_user is provided but smtp_pass is not, instead of prompting for password, make git-send-email use git credential command instead. Signed-off-by: Michal Nazarewicz <mina86@mina86.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-14Merge branch 'nz/send-email-headers-are-case-insensitive'Libravatar Junio C Hamano1-5/+5
When user spells "cc:" in lowercase in the fake "header" in the trailer part, send-email failed to pick up the addresses from there. As e-mail headers field names are case insensitive, this script should follow suit and treat "cc:" and "Cc:" the same way. * nz/send-email-headers-are-case-insensitive: git-send-email: treat field names as case-insensitively
2013-01-06git-send-email: treat field names as case-insensitivelyLibravatar Nickolai Zeldovich1-5/+5
Field names like To:, Cc:, etc. are case-insensitive; use a case-insensitive regexp to match them as such. Previously, git-send-email would fail to pick-up the addresses when in-body "fake" headers with different cases (e.g. lowercase "cc:") are manually inserted to the messages it was asked to send, even though the text will still show them. Signed-off-by: Nickolai Zeldovich <nickolai@csail.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-29Merge branch 'km/send-email-remove-cruft-in-address'Libravatar Junio C Hamano1-18/+59
* km/send-email-remove-cruft-in-address: git-send-email: allow edit invalid email address git-send-email: ask what to do with an invalid email address git-send-email: remove invalid addresses earlier git-send-email: fix fallback code in extract_valid_address() git-send-email: remove garbage after email address
2012-11-26git-send-email: allow edit invalid email addressLibravatar Krzysztof Mazur1-3/+6
In some cases the user may want to send email with "Cc:" line with email address we cannot extract. Now we allow user to extract such email address for us. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-26git-send-email: ask what to do with an invalid email addressLibravatar Krzysztof Mazur1-2/+10
We used to warn about invalid emails and just drop them. Such warnings can be unnoticed by user or noticed after sending email when we are not giving the "final sanity check [Y/n]?" Now we quit by default. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-26git-send-email: remove invalid addresses earlierLibravatar Krzysztof Mazur1-13/+39
Some addresses are passed twice to unique_email_list() and invalid addresses may be reported twice per send_message. Now we warn about them earlier and we also remove invalid addresses. This also removes using of undefined values for string comparison for invalid addresses in cc list processing. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-26send-email: avoid questions when user has an identLibravatar Felipe Contreras1-6/+1
Currently we keep getting questions even when the user has properly configured his full name and password: Who should the emails appear to be from? [Felipe Contreras <felipe.contreras@gmail.com>] And once a question pops up, other questions are turned on. This is annoying. The reason it's safe to avoid this question is because currently the script fails completely when the author (or committer) is not correct, so we won't even be reaching this point in the code. The scenarios, and the current situation: 1) No information at all, no fully qualified domain name fatal: empty ident name (for <felipec@nysa.(none)>) not allowed 2) Only full name fatal: unable to auto-detect email address (got 'felipec@nysa.(none)') 3) Full name + fqdm Who should the emails appear to be from? [Felipe Contreras <felipec@nysa.felipec.org>] 4) Full name + EMAIL Who should the emails appear to be from? [Felipe Contreras <felipe.contreras@gmail.com>] 5) User configured 6) GIT_COMMITTER 7) GIT_AUTHOR All these are the same as 4) After this patch: 1) 2) won't change: git send-email would still die 4) 5) 6) 7) will change: git send-email won't ask the user This is good, that's what we would expect, because the identity is explicit. 3) will change: git send-email won't ask the user This is bad, because we will try with an address such as 'felipec@nysa.felipec.org', which is most likely not what the user wants, but the user will get warned by default (confirm=auto), and if not, most likely the sending won't work, which the user would readily note and fix. The worst possible scenario is that such mail address does work, and the user sends an email from that address unintentionally, when in fact the user expected to correct that address in the prompt. This is a very, very, very unlikely scenario, with many dependencies: 1) No configured user.name/user.email 2) No specified $EMAIL 3) No configured sendemail.from 4) No specified --from argument 5) A fully qualified domain name 6) A full name in the geckos field 7) A sendmail configuration that allows sending from this domain name 8) confirm=never, or 8.1) confirm configuration not hitting, or 8.2) Getting the error, not being aware of it 9) The user expecting to correct this address in the prompt In a more likely scenario where 7) is not the case (can't send from nysa.felipec.org), the user will simply see the mail was not sent properly, and fix the problem. The much more likely scenario though, is where 5) is not the case (nysa.(none)), and git send-email will fail right away like it does now. So the likelihood of this affecting anybody seriously is very very slim, and the chances of this affecting somebody slightly are still very small. The vast majority, if not all, of git users won't be affected negatively, and a lot will benefit from this. Tests-by: Jeff King <peff@peff.net> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-26git-send-email: fix fallback code in extract_valid_address()Libravatar Krzysztof Mazur1-5/+5
In the fallback check, used when Email::Valid is not available, the extract_valid_address() uses $1 without checking for success of matching regex. The $1 variable may still hold the result of previous match, which is the address when email address was in '<>' or be undefined otherwise. Now if match fails undefined value is always returned to indicate error. The same value is used by Email::Valid->address() in that case. Previously 'foo@bar' address was rejected by Email::Valid and fallback, but '<foo@bar>' was rejected by Email::Valid, but accepted by fallback. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-26git-send-email: remove garbage after email addressLibravatar Krzysztof Mazur1-0/+4
In some cases it is useful to add additional information after the email address on the Cc: footer in a commit log, for instance: "Cc: Stable kernel <stable@vger.kernel.org> #v3.4 v3.5 v3.6" However, git-send-email refuses to pick up such an invalid address when the Email::Valid perl module is available, or just uses the whole line as the email address. In sanitize_address(), remove everything after the email address, so that the result is a valid email address that makes Email::Valid happy. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Tested-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-25git-send-email: add rfc2047 quoting for "=?"Libravatar Krzysztof Mazur1-1/+1
For raw subjects rfc2047 quoting is needed not only for non-ASCII characters, but also for any possible rfc2047 in it. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Jeff King <peff@peff.net>
2012-10-25git-send-email: introduce quote_subject()Libravatar Krzysztof Mazur1-6/+19
The quote_rfc2047() always adds RFC2047 quoting. To avoid quoting ASCII subjects, before calling quote_rfc2047() subject must be tested for non-ASCII characters. This patch introduces a new quote_subject() function, which performs the test and calls quote_rfc2047 only if necessary. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Jeff King <peff@peff.net>
2012-10-25git-send-email: skip RFC2047 quoting for ASCII subjectsLibravatar Krzysztof Mazur1-1/+2
The git-send-email always use RFC2047 subject quoting for files with "broken" encoding - non-ASCII files without Content-Transfer-Encoding, even for ASCII subjects. This is harmless but unnecessarily ugly for people reading the raw headers. This patch skips rfc2047 quoting when the subject does not need it. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Jeff King <peff@peff.net>
2012-10-25git-send-email: use compose-encoding for SubjectLibravatar Krzysztof Mazur1-4/+4
The commit "git-send-email: introduce compose-encoding" introduced the compose-encoding option to specify the introduction email encoding (--compose option), but the email Subject encoding was still hardcoded to UTF-8. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Jeff King <peff@peff.net>
2012-10-10git-send-email: introduce compose-encodingLibravatar Krzysztof Mazur1-1/+8
The introduction email (--compose option) have encoding hardcoded to UTF-8, but invoked editor may not use UTF-8 encoding. The encoding used by patches can be changed by the "8bit-encoding" option, but this option does not have effect on introduction email and equivalent for introduction email is missing. Added compose-encoding command line option and sendemail.composeencoding configuration option specify encoding of introduction email. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-14Merge branch 'sb/send-email-reconfirm-fix' into maintLibravatar Junio C Hamano1-2/+4
* sb/send-email-reconfirm-fix: send-email: initial_to and initial_reply_to are both optional
2012-09-14Merge branch 'jc/send-email-reconfirm' into maintLibravatar Junio C Hamano1-3/+13
* jc/send-email-reconfirm: send-email: validate & reconfirm interactive responses
2012-09-12Merge branch 'sb/send-email-reconfirm-fix'Libravatar Junio C Hamano1-2/+4
* sb/send-email-reconfirm-fix: send-email: initial_to and initial_reply_to are both optional
2012-09-06send-email: initial_to and initial_reply_to are both optionalLibravatar Stephen Boyd1-2/+4
We may pick up additional recipients from the format-patch output files we are sending, in which case it is perfectly valid to leave the @initial_to empty when the prompt asks. We may want to start a new discussion thread without replying to anything, and it is valid to leave $initial_reply_to empty. An earlier update to avoid y@example.com stuffed in address fields did not take these two cases into account. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-03Merge branch 'jc/send-email-reconfirm'Libravatar Junio C Hamano1-3/+13
Validate interactive input to "git send-email" to avoid common mistakes such as saying "y<RETURN>" to sender mail address whose prompt is given with a correctly guessed default. * jc/send-email-reconfirm: send-email: validate & reconfirm interactive responses
2012-08-14send-email: validate & reconfirm interactive responsesLibravatar Junio C Hamano1-3/+13
People answer 'y' to "Who should the emails appear to be from?" and 'n' to "Message-ID to be used as In-Reply-To for the first email?" for some unknown reason. While it is possible that your local username really is "y" and you are sending the mail to your local colleagues, it is possible, and some might even say it is likely, that it is a user error. Fortunately, our interactive prompter already has input validation mechanism built-in. Enhance it so that we can optionally reconfirm and allow the user to pass an input that does not validate, and "softly" require input to the sender, in-reply-to, and recipient to contain "@" and "." in this order, which would catch most cases of mistakes. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-31send-email: improve RFC2047 quote parsingLibravatar Thomas Rast1-4/+6
The RFC2047 unquoting, used to parse email addresses in From and Cc headers, is broken in several ways: * It erroneously substitutes ' ' for '_' in *the whole* header, even outside the quoted field. [Noticed by Christoph.] * It is too liberal in its matching, and happily matches the start of one quoted chunk against the end of another, or even just something that looks like such an end. [Noticed by Junio.] * It fundamentally cannot cope with encodings that are not a superset of ASCII, nor several (incompatible) encodings in the same header. This patch fixes the first two by doing a more careful decoding of the outer quoting (e.g. "=AB" to represent an octet whose value is 0xAB). Fixing the fundamental issues is left for a future, more intrusive, patch. Noticed-by: Christoph Miebach <christoph.miebach@web.de> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-09send-email: multiedit is a boolean config optionLibravatar Jeff King1-1/+1
The sendemail.multiedit variable is meant to be a boolean. However, it is not marked as such in the code, which means we store its value literally. Thus in the do_edit function, perl ends up coercing it to a boolean value according to perl rules, not git rules. This works for "0", but "false", "no", or "off" will erroneously be interpreted as true. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-18Merge branch 'md/smtp-tls-hello-again'Libravatar Junio C Hamano1-1/+1
* md/smtp-tls-hello-again: send-email: Honour SMTP domain when using TLS
2011-10-15send-email: Honour SMTP domain when using TLSLibravatar Matthew Daley1-1/+1
git-send-email sends two SMTP EHLOs when using TLS encryption, however only the first, unencrypted EHLO uses the SMTP domain that can be optionally specified by the user (--smtp-domain). This is because the call to hello() that produces the second, encrypted EHLO does not pass the SMTP domain as an argument, and hence a default of 'localhost.localdomain' is used instead. Fix by passing in the SMTP domain in this call. Signed-off-by: Matthew Daley <mattjd@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-14send-email: Fix %config_path_settings handlingLibravatar Cord Seele1-2/+10
cec5dae (use new Git::config_path() for aliasesfile, 2011-09-30) broke the expansion of aliases. This was caused by treating %config_path_settings, newly introduced in said patch, like %config_bool_settings instead of like %config_settings. Copy from %config_settings, making it more readable. While at it add basic test for expansion of aliases, and for path expansion, which would catch this error. Nb. there were a few issues that were responsible for this error: 1. %config_bool_settings and %config_settings despite similar name have different semantic. %config_bool_settings values are arrays where the first element is (reference to) the variable to set, and second element is default value... which admittedly is a bit cryptic. More readable if more verbose option would be to use hash reference, e.g.: my %config_bool_settings = ( "thread" => { variable => \$thread, default => 1}, [...] %config_settings values are either either reference to scalar variable or reference to array. In second case it means that option (or config option) is multi-valued. BTW. this is similar to what Getopt::Long does. 2. In cec5dae (use new Git::config_path() for aliasesfile, 2011-09-30) the setting "aliasesfile" was moved from %config_settings to newly introduced %config_path_settings. But the loop that parses settings from %config_path_settings was copy'n'pasted *wrongly* from %config_bool_settings instead of from %config_settings. It looks like cec5dae author cargo-culted this change... 3. 994d6c6 (send-email: address expansion for common mailers, 2006-05-14) didn't add test for alias expansion to t9001-send-email.sh Signed-off-by: Cord Seele <cowose@gmail.com> Tested-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-12Merge branch 'cs/perl-config-path-send-email'Libravatar Junio C Hamano1-1/+9
* cs/perl-config-path-send-email: use new Git::config_path() for aliasesfile Add Git::config_path()
2011-10-12Merge branch 'zj/send-email-authen-sasl'Libravatar Junio C Hamano1-0/+6
* zj/send-email-authen-sasl: send-email: auth plain/login fix
2011-09-30use new Git::config_path() for aliasesfileLibravatar Cord Seele1-1/+9
Signed-off-by: Cord Seele <cowose@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>