Re: [PATCH 1/4] sha1-lookup: add new "sha1_pos" function to efficiently lookup sha1

On Sun, Apr 05, 2009 at 08:31:06PM +0100, Reece Dunn wrote:

This is what `base64 -d` gives:
[...]
It's not "going to be", but "has been so for the last two years since
5d23e13".

It is an assert, and I think Peff's die("BUG: ...") would be a good idea.

Interestingly, I get a bunch of unprintable crap at the end. The culprit
seems to be that vger stupidly adds:

    --
    To unsubscribe from this list: send the line "unsubscribe git" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html

to the bottom, regardless of transfer-encoding. At best, this is
pointless and invisible, as the reader will just show the base64
content. But some decoders (like mutt) actually treat non-base64
characters not as "end of base64" but as "ignore and keep looking for
more base64". So this decodes into a bunch of random characters. And to
make it even more fun, it only happens if the message is a certain
length; otherwise, it needs "=" fill characters at the end, which
unambiguously signal the end.

"openssl base64 -d" stops decoding at the cruft. But I think what mutt
is doing is right. According to RFC 2045:

     The encoded output stream must be represented in lines of no more
     than 76 characters each.  All line breaks or other characters not
     found in Table 1 must be ignored by decoding software.  In base64
     data, characters other than those in Table 1, line breaks, and
     other white space probably indicate a transmission error, about
     which a warning message or even a message rejection might be
     appropriate under some circumstances.

I don't know if it is worth trying to get vger to be smarter. According
to this, they consider base64 text parts not worth handling:

  http://lkml.indiana.edu/hypermail/linux/kernel/0304.0/0901.html

So maybe it is worth trying to get Junio not to send base64 mail. ;)

-Peff