Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API

Hello Ignace, $input or $data instead of $decoded (could actually do the same instead of $encoded, but that one doesn't feel as wrong) >> > Usage of `$encoded` and `$decoded` as parameter names is done to emphasize > the *state of the data**,* rather than its format. This is helpful as it > avoi

Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API

On Mon, Jul 14, 2025 at 11:26 PM Andrey Andreev wrote: > Hi all, > > I have a few suggestions, starting with naming improvements: > - Forgiving instead of Lenient (align with > https://infra.spec.whatwg.org/#forgiving-base64) > - Shorten the option names; one example would be Variable/Constant in

Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API

Hi all, I have a few suggestions, starting with naming improvements: - Forgiving instead of Lenient (align with https://infra.spec.whatwg.org/#forgiving-base64) - Shorten the option names; one example would be Variable/Constant instead of Unprotected/ConstantTime, but I think most could be rethink

Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API

Hi all, I have updated the RFC to include a section outlining the migration path . Since the proposed migration strategy for base64_decode() *may be considered controversial*, I plan to submit it as an *optional vote*—allowing contributors

Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API

On Wed, Jul 2, 2025, at 2:25 PM, ignace nyamagana butera wrote: >> >> I don't think it needs to be added to the enum, necessarily. Just make it a >> nullable argument to base64_decode. >> >> function base64_decode(string $string, bool $strict = false, ?DecodingMode = >> null): string|false >>

Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API

> > > I don't think it needs to be added to the enum, necessarily. Just make it > a nullable argument to base64_decode. > > function base64_decode(string $string, bool $strict = false, ?DecodingMode > = null): string|false > > That would leave the default behavior of the function intact, but also

Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API

On Wed, Jul 2, 2025, at 10:10 AM, ignace nyamagana butera wrote: >> > Perhaps we should include an option in the new API to emulate the old >> > behaviour, named as "legacy" or "unsafe" and immediately soft-deprecated >> > with a note in the manual, similar to the MT_RAND_PHP mode in the >> > Ra

Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API

> > > Perhaps we should include an option in the new API to emulate the old > behaviour, 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.php.net/manual/en/random-engine-mt19937.constru

Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API

On 1 July 2025 22:27:14 BST, ignace nyamagana butera wrote:] >- 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===0bw??',

Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API

Hi Larry, I have updated the wording of the RFC to give the reason for the default selected variant for each function family. I have also dropped the Variant suffix from the algorithm variant enum. Hope this answers your remarks On Tue, Jul 1, 2025 at 4:20 PM Larry Garfield wrote: > On Fri, Ju

Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API

On Tue, Jul 1, 2025 at 1:09 PM Rowan Tommins [IMSoP] wrote: > > > On 19 June 2025 12:01:04 BST, ignace nyamagana butera > 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

Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API

On Tue, Jul 1, 2025, at 9:32 AM, Tim Düsterhus wrote: >> For the long-names issue that Tim pointed out, perhaps drop "Variant" >> from the enum names? As they're namespaced, `Base32::Ascii` seems >> fairly self-explanatory. > > You probably meant s/Tim/Rowan/. > > Best regards > Tim Düsterhus

Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API

Hi Am 2025-07-01 16:18, schrieb Larry Garfield: I don't follow. Every function listed allows a timing mode to be set, so I presume that means every function *can* use constant-time. The implementation is, well, this RFC. :-) So I don't see why we can't just force constant-time everywhere an

Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API

On Fri, Jun 20, 2025, at 3:17 AM, ignace nyamagana butera wrote: > - 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 > Base6

Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API

On 19 June 2025 12:01:04 BST, ignace nyamagana butera 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 namespac

Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API

Hi all, I have updated the RFC (https://wiki.php.net/rfc/data_encoding_api) to include base58 encoding and decoding functions to the proposal with arguments in favor of the addition. Best regards, Ignace On Fri, Jun 20, 2025 at 10:17 AM ignace nyamagana butera < nyamsp...@gmail.com> wrote: > T

Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API

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 i

Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API

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. >