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

Linked PRs

• gh-146311: Reject non-zero padding bits in base64/base32 decoding #146312