Invalid responses to 8bit encoding and In-Reply-To questions

Invalid responses to 8bit encoding and In-Reply-To questions

[Geert Uytterhoeven]

>From a thread on another mailing list:
| > Content-Type: text/plain; charset=y
| > Content-Transfer-Encoding: 8bit
| >
| > When I try to apply it git am says:
| >
| > $ git am --signoff geert1.patch
| > fatal: cannot convert from y to UTF-8
| >
| > Wut? I never heard of an encoding named "y", and SMTP is
| > not my strongest subject anyway.
|
| Oops, I'm afraid automatic-I replied "y" to the git-send-email question
| "Which 8bit encoding should I declare [UTF-8]?"
| (happened before with the In-Reply-To questions ;-(

Would it be possible to reject obviously wrong replies ("y", "yes", "n", "no")
to the 8bit encoding and In-Reply-To questions?

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Invalid responses to 8bit encoding and In-Reply-To questions

[Junio C Hamano]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

> | Oops, I'm afraid automatic-I replied "y" to the git-send-email question
> | "Which 8bit encoding should I declare [UTF-8]?"
> | (happened before with the In-Reply-To questions ;-(
>
> Would it be possible to reject obviously wrong replies ("y", "yes", "n", "no")
> to the 8bit encoding and In-Reply-To questions?

There is no canned configuration to do so, if that is what you are
asking.

It would be possible to do so with code changes to git-send-email;
look for "ask(", "valid_re", and "confirm_only" to see how they are
used in existing code that ask questions, if you are interested.

Re: [Qemu-devel] [PATCH v3 0/7] cpu: add device_add foo-x86_64-cpu support

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]

[adding git list to cc]

On 02/05/2015 04:49 AM, Stefan Hajnoczi wrote:
> On Wed, Jan 14, 2015 at 03:27:23PM +0800, Zhu Guihua wrote:
>> This series is based on the previous patchset from Chen Fan:
>> https://lists.nongnu.org/archive/html/qemu-devel/2014-05/msg02360.html
> 
> This email has an invalid charset:
> Content-Type: text/plain; charset="y"
> 
> I guess you entered "y" when asked how the message was encoded.
> 
> Please don't do that, it means we can only guess at the charset.

In the past, people made a similar problem when 'git send-email' was
asking if a message was in-reply-to something else (the number of
messages incorrectly threaded to a message-id of 'y' or 'n' was evidence
of the poor quality of the question).  git.git commit 51bbccfd1b4a
corrected that problem.  Sounds like charset encoding is another case
where the interactive parser should be taught to balk at nonsense
encoding answers?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] [PATCH v3 0/7] cpu: add device_add foo-x86_64-cpu support

[Junio C Hamano]

Eric Blake <eblake@redhat.com> writes:

> On 02/05/2015 04:49 AM, Stefan Hajnoczi wrote:
>> On Wed, Jan 14, 2015 at 03:27:23PM +0800, Zhu Guihua wrote:
>>> This series is based on the previous patchset from Chen Fan:
>>> https://lists.nongnu.org/archive/html/qemu-devel/2014-05/msg02360.html
>> 
>> This email has an invalid charset:
>> Content-Type: text/plain; charset="y"
>> 
>> I guess you entered "y" when asked how the message was encoded.
>> 
>> Please don't do that, it means we can only guess at the charset.
>
> In the past, people made a similar problem when 'git send-email' was
> asking if a message was in-reply-to something else (the number of
> messages incorrectly threaded to a message-id of 'y' or 'n' was evidence
> of the poor quality of the question).  git.git commit 51bbccfd1b4a
> corrected that problem.  Sounds like charset encoding is another case
> where the interactive parser should be taught to balk at nonsense
> encoding answers?

I think I answered this in $gmane/263354; care to come up with a
plausible valid_re?  It is inpractical to attempt to cover all valid
charset names, so whatever you do I'd imagine you would want to pass
the confirm_only parameter set to true.

Re: [Qemu-devel] [PATCH v3 0/7] cpu: add device_add foo-x86_64-cpu support

[Jeff King]

On Thu, Feb 05, 2015 at 11:29:07AM -0800, Junio C Hamano wrote:

> Eric Blake <eblake@redhat.com> writes:
> 
> > On 02/05/2015 04:49 AM, Stefan Hajnoczi wrote:
> >> On Wed, Jan 14, 2015 at 03:27:23PM +0800, Zhu Guihua wrote:
> >>> This series is based on the previous patchset from Chen Fan:
> >>> https://lists.nongnu.org/archive/html/qemu-devel/2014-05/msg02360.html
> >> 
> >> This email has an invalid charset:
> >> Content-Type: text/plain; charset="y"
> >> 
> >> I guess you entered "y" when asked how the message was encoded.
> >> 
> >> Please don't do that, it means we can only guess at the charset.
> >
> > In the past, people made a similar problem when 'git send-email' was
> > asking if a message was in-reply-to something else (the number of
> > messages incorrectly threaded to a message-id of 'y' or 'n' was evidence
> > of the poor quality of the question).  git.git commit 51bbccfd1b4a
> > corrected that problem.  Sounds like charset encoding is another case
> > where the interactive parser should be taught to balk at nonsense
> > encoding answers?
> 
> I think I answered this in $gmane/263354; care to come up with a
> plausible valid_re?  It is inpractical to attempt to cover all valid
> charset names, so whatever you do I'd imagine you would want to pass
> the confirm_only parameter set to true.

Would "length() > 1" be enough[1]? Or are people really typing "yes" and
not just "y"?

I cannot imagine a charset name that is smaller than two characters. It
may be that there are none smaller than 4, and we could cut it off
there. Googling around for some lists of common charsets, it seems like
that might be plausible (but not any larger; "big5" is 4 characters, and
people may spell "utf8" without the hyphen).

-Peff

[1] Of course, to match the existing regex code, we may want to spell
    this as "/../" or "/..../".

Re: [Qemu-devel] [PATCH v3 0/7] cpu: add device_add foo-x86_64-cpu support

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Thu, Feb 05, 2015 at 11:29:07AM -0800, Junio C Hamano wrote:
>
>> Eric Blake <eblake@redhat.com> writes:
>> 
>> > On 02/05/2015 04:49 AM, Stefan Hajnoczi wrote:
>> >> On Wed, Jan 14, 2015 at 03:27:23PM +0800, Zhu Guihua wrote:
>> >>> This series is based on the previous patchset from Chen Fan:
>> >>> https://lists.nongnu.org/archive/html/qemu-devel/2014-05/msg02360.html
>> >> 
>> >> This email has an invalid charset:
>> >> Content-Type: text/plain; charset="y"
>> >> 
>> >> I guess you entered "y" when asked how the message was encoded.
>> >> 
>> >> Please don't do that, it means we can only guess at the charset.
>> >
>> > In the past, people made a similar problem when 'git send-email' was
>> > asking if a message was in-reply-to something else (the number of
>> > messages incorrectly threaded to a message-id of 'y' or 'n' was evidence
>> > of the poor quality of the question).  git.git commit 51bbccfd1b4a
>> > corrected that problem.  Sounds like charset encoding is another case
>> > where the interactive parser should be taught to balk at nonsense
>> > encoding answers?
>> 
>> I think I answered this in $gmane/263354; care to come up with a
>> plausible valid_re?  It is inpractical to attempt to cover all valid
>> charset names, so whatever you do I'd imagine you would want to pass
>> the confirm_only parameter set to true.
>
> Would "length() > 1" be enough[1]? Or are people really typing "yes" and
> not just "y"?
>
> I cannot imagine a charset name that is smaller than two characters. It
> may be that there are none smaller than 4, and we could cut it off
> there. Googling around for some lists of common charsets, it seems like
> that might be plausible (but not any larger; "big5" is 4 characters, and
> people may spell "utf8" without the hyphen).
>
> -Peff
>
> [1] Of course, to match the existing regex code, we may want to spell
>     this as "/../" or "/..../".

Perhaps. Just in case there were shorter ones, something like this
with confirm_only to allow them to say "Yes, I do mean 'xx'"?

 git-send-email.perl | 1 +
 1 file changed, 1 insertion(+)

diff --git a/git-send-email.perl b/git-send-email.perl
index 3092ab3..848f176 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -752,6 +752,7 @@ sub file_declares_8bit_cte {
 		print "    $f\n";
 	}
 	$auto_8bit_encoding = ask("Which 8bit encoding should I declare [UTF-8]? ",
+				  valid_re => qr/.{4}/, confirm_only => 1,
 				  default => "UTF-8");
 }
 

Re: [Qemu-devel] [PATCH v3 0/7] cpu: add device_add foo-x86_64-cpu support

[Jeff King]

On Thu, Feb 05, 2015 at 12:17:15PM -0800, Junio C Hamano wrote:

> > Would "length() > 1" be enough[1]? Or are people really typing "yes" and
> > not just "y"?
> >
> > I cannot imagine a charset name that is smaller than two characters. It
> > may be that there are none smaller than 4, and we could cut it off
> > there. Googling around for some lists of common charsets, it seems like
> > that might be plausible (but not any larger; "big5" is 4 characters, and
> > people may spell "utf8" without the hyphen).
> >
> > -Peff
> >
> > [1] Of course, to match the existing regex code, we may want to spell
> >     this as "/../" or "/..../".
> 
> Perhaps. Just in case there were shorter ones, something like this
> with confirm_only to allow them to say "Yes, I do mean 'xx'"?
> 
>  git-send-email.perl | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 3092ab3..848f176 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -752,6 +752,7 @@ sub file_declares_8bit_cte {
>  		print "    $f\n";
>  	}
>  	$auto_8bit_encoding = ask("Which 8bit encoding should I declare [UTF-8]? ",
> +				  valid_re => qr/.{4}/, confirm_only => 1,
>  				  default => "UTF-8");
>  }

Yes, I think leaving an escape hatch is a good idea, just in case.

-Peff

[PATCH] send-email: ask confirmation if given encoding name is very short

[Junio C Hamano]

Sometimes people respond "y<ENTER>" (or "yes<ENTER>") when asked
this question:

    Which 8bit encoding should I declare [UTF-8]?

We already have a mechanism to avoid accepting a mistyped e-mail
address (we ask to confirm when the given address lacks "@" in it);
reuse it to trigger the same confirmation when given a very short
answer.  As a typical charset name is probably at least 4 chars or
longer (e.g. "UTF8" spelled without the dash, or "Big5"), this would
prevent such a mistake.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 * Will mark to be merged to 'next'.

 git-send-email.perl | 1 +
 1 file changed, 1 insertion(+)

diff --git a/git-send-email.perl b/git-send-email.perl
index fdb0029..eb32371 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -733,6 +733,7 @@ sub file_declares_8bit_cte {
 		print "    $f\n";
 	}
 	$auto_8bit_encoding = ask("Which 8bit encoding should I declare [UTF-8]? ",
+				  valid_re => qr/.{4}/, confirm_only => 1,
 				  default => "UTF-8");
 }
 
-- 
2.3.0-282-gf18c841

Re: [PATCH] send-email: ask confirmation if given encoding name is very short

[Jeff King]

On Mon, Feb 16, 2015 at 02:34:14PM -0800, Junio C Hamano wrote:

> Sometimes people respond "y<ENTER>" (or "yes<ENTER>") when asked
> this question:
> 
>     Which 8bit encoding should I declare [UTF-8]?
> 
> We already have a mechanism to avoid accepting a mistyped e-mail
> address (we ask to confirm when the given address lacks "@" in it);
> reuse it to trigger the same confirmation when given a very short
> answer.  As a typical charset name is probably at least 4 chars or
> longer (e.g. "UTF8" spelled without the dash, or "Big5"), this would
> prevent such a mistake.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> 
>  * Will mark to be merged to 'next'.

Probably belated review, but this looks good to me.

-Peff

Re: Invalid responses to 8bit encoding and In-Reply-To questions

[Guilhem Bichot]

Junio C Hamano <gitster <at> pobox.com> writes:

> 
> Geert Uytterhoeven <geert <at> linux-m68k.org> writes:
> 
> > | Oops, I'm afraid automatic-I replied "y" to the git-send-email question
> > | "Which 8bit encoding should I declare [UTF-8]?"
> > | (happened before with the In-Reply-To questions ;-(
> >
> > Would it be possible to reject obviously wrong replies ("y", "yes", "n",
"no")
> > to the 8bit encoding and In-Reply-To questions?
> 
> There is no canned configuration to do so, if that is what you are
> asking.
> 
> It would be possible to do so with code changes to git-send-email;
> look for "ask(", "valid_re", and "confirm_only" to see how they are
> used in existing code that ask questions, if you are interested.

Today I stumbled on exactly this; a colleague had probably typed "yes" when
inappropriate, and the email I received from git-send-email had:

Content-Type: text/plain; charset=yes

then "git am" complained.

Re: Invalid responses to 8bit encoding and In-Reply-To questions

[Junio C Hamano]

Guilhem Bichot <guilhem.bichot@oracle.com> writes:

> Junio C Hamano <gitster <at> pobox.com> writes:
>
>> It would be possible to do so with code changes to git-send-email;
>> look for "ask(", "valid_re", and "confirm_only" to see how they are
>> used in existing code that ask questions, if you are interested.
>
> Today I stumbled on exactly this; a colleague had probably typed "yes" when
> inappropriate, and the email I received from git-send-email had:
>
> Content-Type: text/plain; charset=yes

Then upcoming release Git 2.4.0 will delight you ;-)