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

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Date: Wed, 18 Apr 2018 00:22:42 +0200
>> Cc: 10536@debbugs.gnu.org
>> 
>> > --- 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);
>> 
>> It probably won't harm anything to add this patch...  On the other hand,
>> it's not very common to have base64 encoded data that fails in this
>> manner.
>> 
>> What do the rest of you people think?  (I think I'm slightly for
>> applying the patch.  "Be liberal in what you receive" and all that.)
>

That principle is starting to change: "Be intolerant in what you
receive, else malicious actors will exploit your tolerance" is
starting to become more common.

> Could this "omission" be a sign of malicious stuff in there?  If so,
> maybe it's better to introduce a variable that would allow this to be
> tolerated, and by default fail with a message telling the user that if
> they trust the source of the data, set the variable and retry?

You mean that someone would deliberately send incorrect base64 in the
hope that interim attachment scanners would ignore it, but that the
final recipient's software would be tolerant and decode it? That seems
a little farfetched [1], but if it really is uncommon, then a variable
would not do much harm.

Robert

Footnotes:
[1]  Then again, someone just hacked a casino via an aquarium
     thermometer, so who am I to judge whatʼs farfetched.