Bug description:
CPython has had this behavior forever on these, but base64 and base32 decode both ignore excess bits in their input data. Per https://datatracker.ietf.org/doc/html/rfc4648.html#section-3.5 "decoders MAY chose to reject an encoding if the pad bits have not been set to zero".
a2b_base64() has a strict_mode= option, so doing this in that mode makes sense.
base32 is documented as always being strict so just fixing its glitch there makes sense to me. We could add a strict_mode= parameter to a2b_base32() but that would be a little sad. I doubt anyone depends on a behavior like this. It is unnatural to have excess bits in encoded data because encoders MUST (per the rfc) set those bits to 0.
This is a follow on to these recent changes:
- Excess Base64 data ignored after padding by default #145264
- C accelerator for Base32 character encoding #146192
CPython versions tested on:
3.15alpha