# [PATCH] send-email: add extra safetly in address sanitazion

4 messages from 2012-02-04 to 2012-02-05. Participants: Felipe Contreras, Junio C Hamano.
Thread: https://gitlist.dev/t/29543

## Felipe Contreras, 2012-02-04 15:10

Subject: [PATCH] send-email: add extra safetly in address sanitazion
Message-ID: <1328368255-10591-1-git-send-email-felipe.contreras@gmail.com>
URL: https://gitlist.dev/e/1328368255-10591-1-git-send-email-felipe.contreras%40gmail.com

```
Otherwise, 'git send-email' would be happy to do:

 % git send-email --to '<foo@bar.com>>'

And use '<foo@bar.com>>' in the headers.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 git-send-email.perl |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/git-send-email.perl b/git-send-email.perl
index ef30c55..b8bf014 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -889,7 +889,7 @@ sub is_rfc2047_quoted {
 # use the simplest quoting being able to handle the recipient
 sub sanitize_address {
 	my ($recipient) = @_;
-	my ($recipient_name, $recipient_addr) = ($recipient =~ /^(.*?)\s*(<.*)/);
+	my ($recipient_name, $recipient_addr) = ($recipient =~ /^(.*?)\s*(<.*?>)/);
 
 	if (not $recipient_name) {
 		return $recipient;
-- 
1.7.9

```

## Felipe Contreras, 2012-02-04 15:26

Subject: Re: [PATCH] send-email: add extra safetly in address sanitazion
Message-ID: <CAMP44s0xfbxLs_r81ppO9hYf3ML_gaYCaW3TKpLM=BjfaM8vHg@mail.gmail.com>
URL: https://gitlist.dev/e/CAMP44s0xfbxLs_r81ppO9hYf3ML_gaYCaW3TKpLM%3DBjfaM8vHg%40mail.gmail.com
In-Reply-To: <1328368255-10591-1-git-send-email-felipe.contreras@gmail.com>

```
On Sat, Feb 4, 2012 at 5:10 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> Otherwise, 'git send-email' would be happy to do:
>
>  % git send-email --to '<foo@bar.com>>'
>
> And use '<foo@bar.com>>' in the headers.

Er, actually that's not correct: '<foo@bar.com>>' will remain the
same, but 'Foo <foo@bar.com>>' will be sanitized.

-- 
Felipe Contreras

```

## Junio C Hamano, 2012-02-05 21:12

Subject: Re: [PATCH] send-email: add extra safetly in address sanitazion
Message-ID: <7v4nv5gf2n.fsf@alter.siamese.dyndns.org>
URL: https://gitlist.dev/e/7v4nv5gf2n.fsf%40alter.siamese.dyndns.org
In-Reply-To: <CAMP44s0xfbxLs_r81ppO9hYf3ML_gaYCaW3TKpLM=BjfaM8vHg@mail.gmail.com>

```
Felipe Contreras <felipe.contreras@gmail.com> writes:

> On Sat, Feb 4, 2012 at 5:10 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> Otherwise, 'git send-email' would be happy to do:
>>
>>  % git send-email --to '<foo@bar.com>>'
>>
>> And use '<foo@bar.com>>' in the headers.
>
> Er, actually that's not correct: '<foo@bar.com>>' will remain the
> same, but 'Foo <foo@bar.com>>' will be sanitized.

I suspect that this "Er" is merely a sympotom of a larger issue in the
approach taken by this patch.  The code takes a potentially malformed
input, and applies a rewrite logic without telling the user what it is
doing.  If the rewrite logic is perfect, that may be OK, but if not, the
logic to rewrite may or may not trigger, or when it triggers it may or may
not produce a correct result, and it all depends on the nature of breakage
in the input.

Wouldn't a better approach to detect problem on the input side and reject
a wrong one by erroring out, so that the user has a chance to fix?

```

## Felipe Contreras, 2012-02-05 21:20

Subject: Re: [PATCH] send-email: add extra safetly in address sanitazion
Message-ID: <CAMP44s1NrGkz7sKz2CTF2XV9uGUfethg2+pcybPe2KBY02cnwA@mail.gmail.com>
URL: https://gitlist.dev/e/CAMP44s1NrGkz7sKz2CTF2XV9uGUfethg2%2BpcybPe2KBY02cnwA%40mail.gmail.com
In-Reply-To: <7v4nv5gf2n.fsf@alter.siamese.dyndns.org>

```
On Sun, Feb 5, 2012 at 11:12 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Sat, Feb 4, 2012 at 5:10 PM, Felipe Contreras
>> <felipe.contreras@gmail.com> wrote:
>>> Otherwise, 'git send-email' would be happy to do:
>>>
>>>  % git send-email --to '<foo@bar.com>>'
>>>
>>> And use '<foo@bar.com>>' in the headers.
>>
>> Er, actually that's not correct: '<foo@bar.com>>' will remain the
>> same, but 'Foo <foo@bar.com>>' will be sanitized.
>
> I suspect that this "Er" is merely a sympotom of a larger issue in the
> approach taken by this patch.  The code takes a potentially malformed
> input, and applies a rewrite logic without telling the user what it is
> doing.

That's what the function is doing already: sanitizing the address.

> Wouldn't a better approach to detect problem on the input side and reject
> a wrong one by erroring out, so that the user has a chance to fix?

Perhaps, but the code is not prepared for that. Anyway, feel free to
drop it, I am not interested in pursing this.

Cheers.

-- 
Felipe Contreras

```
