java.util.Base64 accepts non-canonical encodings

[Roger Riggs]

Hi,

This is a case where having some more interoperability testing could be 
informative
though there are likely many adhoc Base64 encoders and its not practical 
to test
against them.

Introducing a new mode or option creates an undesirable fuzzyness to the 
API.

It won't help existing uses without some deliberate attempt to move 
clients to use
the new option (deprecation). Its not likely to be picked up by new 
clients because
the difference is behavior is slight and may not be seen as important.
An options also tend to live forever, increasing maintenace on both the 
library and
the callers.

Its worth creating a separate issue and looking at it separately.

Thanks, Roger


On 6/23/20 10:50 AM, Raffaello Giulietti wrote:
> Hi Roger,
>
> I didn't yet implement the strict check since, as you point out, it 
> could harm existing code in the wild, even if the OpenJDK test would 
> all pass.
>
> That's why I'm wondering if it would make sense to extend the existing 
> API to have the check as an additional option.
>
>
> Greetings
> Raffaello
>
>
>> Hi Raffaello,
>>
>> I think the concern over accepting non-canonical encodings would be 
>> compatibility.
>> It would rude to implement the strictness and have applications start 
>> failing.
>> But it is likely an oversight since existing code checks for other 
>> invalid encodings.
>>
>> Do any of the existing tests fail if the non-canonical encoding throws?
>>
>> Thanks, Roger
>>
>>
>> On 6/23/20 9:00 AM, Raffaello Giulietti wrote:
>>> Hi,
>>>
>>> RFC 4648, in section "3.5. Canonical Encoding", prescribes that pad 
>>> bits must be set to zero.
>>>
>>> However, the current decoder implementation in java.util.Base64 
>>> accepts non-canonical encodings as well. For example, all of the 
>>> following four encodings
>>> KCk=
>>> KCl=
>>> KCm=
>>> KCn=
>>> where only the first is canonical, decode to the sequence of two 
>>> bytes 0x28 0x29. Padding positions could act as a (very low 
>>> bandwidth) covert channel.
>>>
>>> Since I'm preparing a patch for [1] (see [2]), I'm asking if this is 
>>> intentional behavior or if it is an oversight. Of course, checking 
>>> for strictness would slightly impact performance.
>>>
>>> If checking for non-zero padding bits is desired, should the API be 
>>> extended to allow for both the strict and the (current) lenient 
>>> behaviors? Would the current API suffice?
>>>
>>>
>>> Greetings
>>> Raffaello
>>>
>>> ----
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8222187
>>> [2] 
>>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067066.html