binascii base64 & base32 decode ignore excess padding bits in their input

[gpshead]

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

[gpshead]

@serhiy-storchaka thoughts on what to do about base32 here? it is an observable behavior change, but I don't intend to backport this. Should it gain a strict_mode= parameter like base64 has so that anyone depending on the behavior has an easy way out?

[serhiy-storchaka]

This option is the least important of all RFC 4648 variations, because it is off by default. It is "decoders MAY chose to reject", not "decoders MAY chose to ignore". On other hand, all other strictness checks should be enabled by default. I think that strict_mode should be True by default, strict_mode=False should only be supported for backward compatibility, but there should be other options to disable different strictness checks. For example, ignorechars covers some of such options (ignoring newlines/whitespaces/non-alphabetic characters/"=" not at the end).

I think that:

• it is not a big deal if we continue to ignore the lowest bits in the last quad for a while
• if we add an option, it should be independent from strict_mode.

There are still several issues with higher priority (#73613, #71986/#76672/#64331). This issue can wait.