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

From: Jeff King <peff@peff.net>
Date: Apr 5, 2009, 20:17 UTC
Message-ID: <20090405201700.GC4716@coredump.intra.peff.net>
In-Reply-To: <3f4fd2640904051231x17117a4g3efe38067c8d3359@mail.gmail.com>

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

Show 6 quoted lines

> 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