Re: Disallowing random garbage in base64 data

Hrvoje Niksic <[email protected]> writes:

> Our built-in base64 decoder silently tolerates random garbage in
> base64 data, based on superficial reading of section 6.8 of rfc2045.
>
> For example, (base64-decode-string "AAAA") returns three \0
> characters, but so does (base64-decode-string "AA:[]\\;;;;$#@!AA").
> While allowing white space to appear anywhere in base64 stream is
> clearly beneficial (I consider recode way too strict in that
> department), I can't think of any benefit of allowing other garbage to
> pass unchecked, and can think of problems that this behavior causes.

I agree, and, IIRC, this came up as a problem in Gnus recently.  RFC
3548 also touches on this slightly, and I think the intention was to
suggest that ignoring non-alphabet data is usually not a good idea.