Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127833
Feedback-ID: id5114917:Fastmail
Date: Wed, 02 Jul 2025 13:55:07 +0100
To: PHP Internals List <internals@lists.php.net>
Subject: =?US-ASCII?Q?Re=3A_=5BPHP-DEV=5D_=5BRFC=5D=5BDISCUSSION=5D_Add_?=
 =?US-ASCII?Q?RFC_4648_compliant_data_encoding_API?=
User-Agent: K-9 Mail for Android
In-Reply-To: <CAOV5rgaKkR-y3Hu9Fs0_ty2wT5MoYLDJ_OTH-nDBA-g__t4VEA@mail.gmail.com>
References: <CAOV5rgZjxhe+75YD13wWFRNghbS4fbUrJVouPtbUv9RdpKSAXw@mail.gmail.com> <348856E5-6A4E-455A-81AE-882832170168@rwec.co.uk> <CAOV5rgaKkR-y3Hu9Fs0_ty2wT5MoYLDJ_OTH-nDBA-g__t4VEA@mail.gmail.com>
Message-ID: <AE53E18F-A195-4D40-8BD1-D75AAFE07F92@rwec.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")



On 1 July 2025 22:27:14 BST, ignace nyamagana butera <nyamsprod@gmail=2Eco=
m> wrote:]=20
>- The current base64_decode function operates in a lenient mode by defaul=
t,
>accepting characters outside the valid Base64 alphabet and ignoring
>the padding character wherever it is in the string=2E
>
> base64_decode('dG9=3D=3D=3D0bw??', false); // returns 'toto'
>
>However, the newly proposed lenient mode aligns with the stricter
>recommendations of RFC 4648, Section 12
><https://www=2Erfc-editor=2Eorg/rfc/rfc4648=2Ehtml#section-12> which advi=
se
>rejecting inputs containing invalid characters due to potential security
>concerns=2E=20


That makes total sense, and I support both the choice of default and stand=
ard-compliant implementation=2E However, it feels like it will be hard to d=
ocument why people should stop using the long-established functions, and ex=
actly what the difference is=2E Putting off the problem until a later RFC i=
s just inviting confusion until then=2E

Perhaps we should include an option in the new API to emulate the old beha=
viour, 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=2Ephp=2Enet/manual/en/random-engine-mt19937=2Econstruct=2Ephp>

Then the legacy base64_decode function could have a note like:=20

> 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=2E

And the main documentation for Encoding\base64_decode could explain all th=
ree modes side by side=2E

What do you think?
Rowan Tommins
[IMSoP]