Follow CPython's padding rules in a2b_base64 - #8570

• This PR follows our AI policy

Summary

binascii.a2b_base64 with strict_mode=True accepts padding that CPython rejects:

>>> binascii.a2b_base64(b'YWJj=', strict_mode=True)
b'abc'                 # CPython: binascii.Error: Excess padding not allowed
>>> binascii.a2b_base64(b'abcd====', strict_mode=True)
b'i\xb7\x1d'           # CPython: binascii.Error: Excess padding not allowed

The flag exists to reject malformed input, so accepting it silently defeats it.

The same loop also drops data in the default mode. It returns as soon as a pad completes a quad, so whatever follows is lost:

>>> binascii.a2b_base64(b'abc=a')
b'i\xb7'               # CPython: b'i\xb7\x1a'

Both come from the same place. CPython counts pads as it goes and decides at the end; this one decides at the first complete pad sequence and never looks at a pad while quad_pos is still 0. The loop now follows CPython: a pad that fits the current quad is consumed, any other pad is ignored outside strict mode, and strict mode names it leading, excess or discontinuous. The tail reports the two lengths no valid encoding can produce.

DecodeError::InvalidPadding was mapped to Incorrect padding, but nothing in the file ever built that variant, so it now carries Excess padding not allowed. The other messages are untouched.

Tests

Lib/test/test_binascii.py already had both cases, marked as expected failures. They run now:

• test_base64_strict_mode, which covers all five padding errors across the four buffer types
• test_base64_excess_data, whose marker had even recorded the symptom (AssertionError: b'i' != b'i\xb7')

What I ran:

• cargo run --release -- -m test test_binascii: 93 tests, 17 skipped, SUCCESS
• cargo run --release -- -m test test_base64: 41 tests, SUCCESS
• cargo test --workspace --exclude rustpython_wasm --exclude rustpython-venvlauncher --exclude rustpython-capi: 41 test binaries, no failures
• cargo fmt --check, and clippy with the flags CI uses: both clean

I also ran the inputs above plus the padding cases around them under CPython 3.14 and this build side by side. Every returned value agrees now. Two error strings still differ, both because of the error decoding base64: prefix that #7993 is already working through, so I left them alone.

AI assistance

Claude Code (claude-opus-5) helped with the comparison against CPython, the loop and this description. I read the final diff and ran the checks above on Linux.

Summary by CodeRabbit

• Bug Fixes
  • Improved Base64 decoding behavior when padding is misplaced or excessive.
  • Strict decoding now provides distinct errors for leading, excess, discontinuous, and trailing data.
  • Updated final-length validation to correctly account for padding.