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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to