Re : Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API
[email protected] (Florent Morselli)
| Newsgroups | php.internals |
|---|---|
| Message-ID | <mAT2T_zJJKdcSDwX0jjVHCwsw2ST_06gXyS33ZsEhpgYeClwDZz6iX8ZW6S3CHCZ4QeQOrn8QP-SpS6oLf67uRPHf7FBGv1qOHrPgsnVhyM=@morselli.fr> |
Hi Ignace,
Some context: I maintain libraries including spomky-labs/base64url, two one-line
functions with 46M downloads. So, strong +1 on getting this into core.
Two gaps in DecodingMode::Strict I would like closed, both verified on 8.5:
// whitespace is skipped, even in strict mode
base64_decode("QUJD\nRA==", true); // "ABCD"
// non-canonical trailing bits are discarded, not checked
base64_decode('QQ==', true) === base64_decode('QR==', true); // true
The RFC keeps whitespace ignored "independent of the mode", but sections
3.1 and 3.3 say the opposite, and in JOSE the signature covers the exact
string received, so skipping whitespace decouples what was verified from
what was decoded. Section 3.5 then lets a decoder reject non-zero pad
bits, and Strict is where that belongs: sixteen strings decode to any
one-byte tail, four to any two-byte tail. WebAuthn credential IDs and JWT
kid values are used as database keys, so that is sixteen spellings of one
credential, fifteen of them outside your unique index.
Smaller point: please state explicitly that Base64::UrlSafe accepts padded
and unpadded input under Strict, and that PreservePadding with it is not a
ValueError. Padded base64url is legal per section 5 and does show up in
the wild.
Happy to help on the base64 implementation and to bring test vectors;
between JOSE, WebAuthn and COSE I have a fairly nasty corpus of
real-world base64url.
Best regards
--
Florent Morselli
Le samedi 5 septembre 2026 à 17:59, ignace nyamagana butera <[email protected]> a écrit :
> Hi all,
> Since my last reply I have updated the RFC:
>
> - RFC Text: https://wiki.php.net/rfc/data_encoding_api
> - Discussion Thread: https://news-web.php.net/php.internals/128069
>
> The main changes are:
>
> - I added functions for base58 and base85 encoding;
> - For completeness, I introduced an error marker class (as per PHP policies) and a specific exception to handle potential encoding errors;
> - I added examples to better explain the expected behaviours during string process;
> - I have updated the migration path from the current/legacy API to the newly proposed API;
>
> Best regards,
> Ignace
signature.asc
(application/pgp-signature, 343 B)
-----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmqcPQoJEBvNRpbgzz1+RRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmfEF9f7o79o3FD4pebwdqwVChVJYL+zhNGEgpNJ 53inARYhBJK2JigheAkh+K1f4RvNRpbgzz1+AACczwEA24peD2Euyy97BgP2 aUbRc+0PonuflQIqdXEah10M1acA/22qk3xZ/C9IDOw1l2bELkFLS6lVH6WP mhNZMAtHMzIE =lnCv -----END PGP SIGNATURE-----