bug#10536: 23.3; Make base64-decode more fault tolerant

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> > --- src/fns.c~     2011-04-05 05:46:44.000000000 +0200
>> > +++ src/fns.c      2012-01-17 13:59:26.000000000 +0100
>> > @@ -3590,7 +3590,8 @@
>> >
>> >        if (c == '=')
>> >    {
>> > -    READ_QUADRUPLET_BYTE (-1);
>> > +    /* Be tolerant against missing final padding '='.  */
>> > +    READ_QUADRUPLET_BYTE (e-to);

[...]

> Could this "omission" be a sign of malicious stuff in there?

Hm...  I don't think so.  This is about the very last characters of a
base64-encoded text.  The standard says that if there are too few bytes
in the original text, then the base64-encoded thing should be padded
with = signs.

Here's an example:

(base64-encode-string "hel")
=> "aGVs"
(base64-encode-string "hell")
=> "aGVsbA=="
(base64-encode-string "hello")
=> "aGVsbG8="
(base64-encode-string "helloh")
=> "aGVsbG9o"

The proposed patch is that base64-decode should handle the end-padding
and missing end-padding equivalently: That is, both "aGVsbA==" and
"aGVsbA" should decode to "hell".

Unless I'm missing something, I don't think there's much room for
maliciousness here...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no