Hi internals,
I'd like to start the discussion for a new RFC about adding RFC 4648
compliant data encoding API
RFC proposal link: https://wiki.php.net/rfc/data_encoding_api
If passed, Tim Düsterhus has volunteered to do the implementation.
Thanks in advance for your remarks and comments.
Best regards,
Ignace Nyamagana Butera
Hi Ignace
I'd like to start the discussion for a new RFC about adding RFC 4648
compliant data encoding API
RFC proposal link: https://wiki.php.net/rfc/data_encoding_api
If passed, Tim Düsterhus has volunteered to do the implementation.Thanks in advance for your remarks and comments.
Best regards,
Ignace Nyamagana Butera
Thanks for the RFC!
Here my doleance about it:
- please make base58 part of the RFC - it's already widely used and having
it implemented in C would be great. See
https://github.com/php/php-src/issues/15195 - it'd be great to default to url-safe base64. The RFC-compliant variant is
a very common risk, it'd be great to be on the safe side by default - why do we need to decide between constant-time and unprotected? Can't we
always go for the constant-time behavior? If not, what about defaulting to
constant-time, again, safe by default? - about DecodingMode, shouldn't this be Lenient by default, following the
robustness principle? - (base85 looks great and would be nice to have also :) )
Cheers,
Nicolas
Thanks for the RFC!
Here my doleance about it:
- please make base58 part of the RFC - it's already widely used and having
it implemented in C would be great. See
https://github.com/php/php-src/issues/15195
I see that there's already a PECL extension for base58. I will see what I
can do because it was listed as a future scope for the moment.
- it'd be great to default to url-safe base64. The RFC-compliant variant is
a very common risk, it'd be great to be on the safe side by default
I went with the RFC recommendation to set up the default. In case of Base64
the URL Safe variant is not the default. While we support URL safe variants
there are plenty of applications which do not expect the URL Safe variant,
for instance, the data URLs do not use the URL Safe variant.
- why do we need to decide between constant-time and unprotected? Can't we
always go for the constant-time behavior? If not, what about defaulting to
constant-time, again, safe by default?
In an ideal world I would use the constant-time behavior everytime, But
this will depend largely on the implementation and if it can be applied to
every scenario hence why I went defensive on this option.
- about DecodingMode, shouldn't this be Lenient by default, following the
robustness principle?
I went with strict by default for security reasons. The Lenient behavior
described is for instance more restrictive than the current "lenient" mode
used by the current base64_decode function. This is due to the security
issues raised by the RFC.
Best regards,
Ignace
On Thu, Jun 19, 2025 at 1:50 PM Nicolas Grekas nicolas.grekas+php@gmail.com
wrote:
Hi Ignace
I'd like to start the discussion for a new RFC about adding RFC 4648
compliant data encoding API
RFC proposal link: https://wiki.php.net/rfc/data_encoding_api
If passed, Tim Düsterhus has volunteered to do the implementation.Thanks in advance for your remarks and comments.
Best regards,
Ignace Nyamagana ButeraThanks for the RFC!
Here my doleance about it:
- please make base58 part of the RFC - it's already widely used and having
it implemented in C would be great. See
https://github.com/php/php-src/issues/15195- it'd be great to default to url-safe base64. The RFC-compliant variant
is a very common risk, it'd be great to be on the safe side by default- why do we need to decide between constant-time and unprotected? Can't we
always go for the constant-time behavior? If not, what about defaulting to
constant-time, again, safe by default?- about DecodingMode, shouldn't this be Lenient by default, following the
robustness principle?- (base85 looks great and would be nice to have also :) )
Cheers,
Nicolas