Canonicity error

[marshallpierce]

Canonicity error

[marshallpierce]

Padding is optional and has no semantic meaning.

[AljoschaMeyer]

The rfc is pretty vague on this.

https://tools.ietf.org/html/rfc4648#section-3.2

Implementations MUST include appropriate pad characters at the end of encoded data unless the specification referring to this document explicitly states otherwise.

https://tools.ietf.org/html/rfc4648#page-6

Since all base 64 input is an integral number of octets, only the following cases can arise: [..]

https://tools.ietf.org/html/rfc4648#section-3.3

If more than the allowed number of pad characters is found at the end of the string (e.g., a base 64 string terminated with "==="), the excess pad characters MAY also be ignored.

In particular the section on canonicity fails to mention this issue at all, which is somewhat disappointing.

The crate parses b"AAAA" into [0, 0, 0], but rejects b"AAAA=" - so it appears to do some checks on padding =s - it just happens to accept AA, AA= and AA== (but not AA===). So what is the exact API of this crate regarding trailing padding? Does it accept any number of padding =s up to the maximum amount that could be produced by the regular encoding algorithm?

I guess a workaround would be pretty easy here (decode, check length of encoded data, check that the canonical amount of padding was available in the encoding), so probably no need to add an option for this in this crate.

[marshallpierce]

Does it accept any number of padding =s up to the maximum amount that could be produced by the regular encoding algorithm?

Yep. It detects that AAAA= is an impossible length (can't have |input| % 4 == 1 or == 5). It has to pay attention to the length at least somewhat because it needs to detect how much of the input it could conceivably do with the fastest type of decoding. Having just 1 padding char when there should be 2 is a bit of an odd case -- it really doesn't do any harm (no padding is ever needed, after all -- IMO it was a mistake to include it in the spec), and it won't cause padding to spill into blocks where it shouldn't exist, so it won't trip anything up. In general I'm pretty vigorously pro-strictness when it comes to parsing, but given that padding is completely useless to begin with, I'm not sure I want to fight the battle of making sure everyone's base64 has correct padding 🤷

[AljoschaMeyer]

Yup, that sounds reasonable. I'm stuck with a legacy system that has to enforce canonicity, but let's hope not many other people will ever have to deal with this... Canonicity can be enforced by checking that |input| % 4 == 0 I think, so that's something that can be easily done outside this crate.

[marshallpierce]

Yep, if you're requiring padding, then it should always be 0.