On 1 July 2025 22:27:14 BST, ignace nyamagana butera <nyamsp...@gmail.com>
wrote:]
>- The current base64_decode function operates in a lenient mode by default,
>accepting characters outside the valid Base64 alphabet and ignoring
>the padding character wherever it is in the string.
>
> base64_decode('dG9===0bw??', false); // returns 'toto'
>
>However, the newly proposed lenient mode aligns with the stricter
>recommendations of RFC 4648, Section 12
><https://www.rfc-editor.org/rfc/rfc4648.html#section-12> which advise
>rejecting inputs containing invalid characters due to potential security
>concerns.
That makes total sense, and I support both the choice of default and
standard-compliant implementation. However, it feels like it will be hard to
document why people should stop using the long-established functions, and
exactly what the difference is. Putting off the problem until a later RFC is
just inviting confusion until then.
Perhaps we should include an option in the new API to emulate the old
behaviour, named as "legacy" or "unsafe" and immediately soft-deprecated with a
note in the manual, similar to the MT_RAND_PHP mode in the Randomizer API
<https://www.php.net/manual/en/random-engine-mt19937.construct.php>
Then the legacy base64_decode function could have a note like:
> This function always uses Mode::LegacyUnsafe, and its use is discouraged;
> consider using the newer Encoding\base64_decode with Mode::Strict or
> Mode::Lenient instead.
And the main documentation for Encoding\base64_decode could explain all three
modes side by side.
What do you think?
Rowan Tommins
[IMSoP]
