Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127829
Precedence: bulk
MIME-Version: 1.0
References: <CAOV5rgZjxhe+75YD13wWFRNghbS4fbUrJVouPtbUv9RdpKSAXw@mail.gmail.com>
 <348856E5-6A4E-455A-81AE-882832170168@rwec.co.uk>
In-Reply-To: <348856E5-6A4E-455A-81AE-882832170168@rwec.co.uk>
Date: Tue, 1 Jul 2025 23:27:14 +0200
Message-ID: <CAOV5rgaKkR-y3Hu9Fs0_ty2wT5MoYLDJ_OTH-nDBA-g__t4VEA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a697a00638e4cfb6"
From: nyamsprod@gmail.com (ignace nyamagana butera)

--000000000000a697a00638e4cfb6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 1, 2025 at 1:09=E2=80=AFPM Rowan Tommins [IMSoP] <imsop.php@rwe=
c.co.uk>
wrote:

>
>
> On 19 June 2025 12:01:04 BST, ignace nyamagana butera <nyamsprod@gmail.co=
m>
> wrote:
> >RFC proposal link: https://wiki.php.net/rfc/data_encoding_api
>
> Thanks for working on this, I have often had to implement base64url and
> been frustrated it's not just a built-in option.
>
> I like the look of the new API. Using namespaced enums is currently quite
> verbose, but that's something we could try to fix at at the language leve=
l
> - e.g. Swift has some nice inference rules, so you can write the equivale=
nt
> of base64_encode($string, ::UrlSafe).
>
> One thing I think the RFC should mention is the future of the existing
> base64_encode/decode functions. Am I right in thinking that with one
> parameter, the new namespaced versions will be identical to the old? If s=
o,
> we have the option to make the existing functions aliases for the new. Or=
,
> we can leave them as-is, but plan to deprecate them. What we probably don=
't
> want is to indefinitely have two versions with such similar names but
> different signatures.
>
> Rowan Tommins
> [IMSoP]
>

 Hi Rowan,

Currently the RFC does not address deprecating the current functions for
the following reasons:

- 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=3D=3D=3D0bw??', 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. Consequently, the behavior differs significantly: while the
current implementation tolerates non-alphabet characters and accepts
padding characters in positions other than at the end of the encoded
string, the proposed version enforces strict validation to enhance security
and compliance with the standard.

Encoding\base64_decode('dG90bw??', DecodingMode::Lenient); // will throw
because of RFC 4648 security recommendation character outside of the base64
alphabet
Encoding\base64_decode('dG9=3D=3D=3D0bw', DecodingMode::Lenient); // will t=
hrow
because of RFC 4648 security recommendation padding character not located
at the end of the string
Encoding\base64_decode('dG90bw', DecodingMode::Lenient); // returns 'toto'

- hex2bin always operates in a lenient mode=E2=80=94it does not support str=
ict
validation. It could be replaced by the new base16_decode function when
configured with appropriate options. However, it's important to note that
the default behavior differs: unlike hex2bin, base16_decode defaults to
strict mode, rejecting invalid input by design, consistent with all newly
proposed decoding functions.

For those reasons, I believe a clear deprecation and removal strategy for
the current functions warrants its own dedicated RFC, as certain features
cannot be easily migrated to the new API.

--000000000000a697a00638e4cfb6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jul 1, =
2025 at 1:09=E2=80=AFPM Rowan Tommins [IMSoP] &lt;<a href=3D"mailto:imsop.p=
hp@rwec.co.uk">imsop.php@rwec.co.uk</a>&gt; wrote:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><br>
<br>
On 19 June 2025 12:01:04 BST, ignace nyamagana butera &lt;<a href=3D"mailto=
:nyamsprod@gmail.com" target=3D"_blank">nyamsprod@gmail.com</a>&gt; wrote:<=
br>
&gt;RFC proposal link: <a href=3D"https://wiki.php.net/rfc/data_encoding_ap=
i" rel=3D"noreferrer" target=3D"_blank">https://wiki.php.net/rfc/data_encod=
ing_api</a><br>
<br>
Thanks for working on this, I have often had to implement base64url and bee=
n frustrated it&#39;s not just a built-in option.<br>
<br>
I like the look of the new API. Using namespaced enums is currently quite v=
erbose, but that&#39;s something we could try to fix at at the language lev=
el - e.g. Swift has some nice inference rules, so you can write the equival=
ent of base64_encode($string, ::UrlSafe).<br>
<br>
One thing I think the RFC should mention is the future of the existing base=
64_encode/decode functions. Am I right in thinking that with one parameter,=
 the new namespaced versions will be identical to the old? If so, we have t=
he option to make the existing functions aliases for the new. Or, we can le=
ave them as-is, but plan to deprecate them. What we probably don&#39;t want=
 is to indefinitely have two versions with such similar names but different=
 signatures.<br>
<br>
Rowan Tommins<br>
[IMSoP]<br></blockquote><div><br></div><div>=C2=A0Hi Rowan,</div><div><br><=
/div><div>Currently the RFC does not address deprecating the current functi=
ons for the following reasons:</div><div><br></div><div>- The current <code=
>base64_decode</code> function operates in a lenient mode by default, accep=
ting characters outside the valid Base64 alphabet and ignoring the=C2=A0pad=
ding character wherever it=C2=A0is in the string.=C2=A0</div><div><br></div=
><div>=C2=A0base64_decode(&#39;dG9=3D=3D=3D0bw??&#39;, false); // returns &=
#39;toto&#39;</div><div><br></div><div>However, the newly proposed lenient =
mode aligns with the stricter recommendations of <a class=3D"gmail-" rel=3D=
"noopener" href=3D"https://www.rfc-editor.org/rfc/rfc4648.html#section-12">=
RFC 4648, Section 12</a>, which advise rejecting inputs containing invalid =
characters due to potential security concerns. Consequently, the behavior d=
iffers significantly: while the current implementation tolerates non-alphab=
et characters and accepts padding characters in positions other than at the=
 end of the encoded string, the proposed version enforces strict validation=
 to enhance security and compliance with the standard.</div><div><br></div>=
<div>Encoding\base64_decode(&#39;dG90bw??&#39;, DecodingMode::Lenient); // =
will throw because of RFC 4648 security recommendation character outside of=
 the base64 alphabet</div><div>Encoding\base64_decode(&#39;dG9=3D=3D=3D0bw&=
#39;, DecodingMode::Lenient); // will throw because of RFC 4648 security re=
commendation padding character not located at the end of the string</div>En=
coding\base64_decode(&#39;dG90bw&#39;, DecodingMode::Lenient); // returns &=
#39;toto&#39;<div><br></div><div>-=C2=A0<code>hex2bin</code> always operate=
s in a lenient mode=E2=80=94it does not support strict validation. It could=
 be replaced by the new <code>base16_decode</code> function when configured=
 with appropriate options. However, it&#39;s important to note that the def=
ault behavior differs: unlike <code>hex2bin</code>, <code>base16_decode</co=
de> defaults to strict mode, rejecting invalid input by design, consistent =
with all newly proposed decoding functions.</div><div><br></div><div>For th=
ose reasons, I believe a clear deprecation and removal strategy for the cur=
rent functions warrants its own dedicated RFC, as certain features cannot b=
e easily migrated to the new API.</div><div><br></div></div></div>

--000000000000a697a00638e4cfb6--