Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:127812 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id BCFCB1A00BC for ; Tue, 1 Jul 2025 07:41:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1751355573; bh=x6gHRIAfYpL6HxjPAP4b6KYYmblwcLhhCFmc4SROqCY=; h=References:In-Reply-To:From:Date:Subject:To:From; b=YflYbYwoUhYisNa60B6Mu3cH7Pq0iVsa+mFSTx2RAddnweftL7whWOuQKU8MDXrY2 /DnCt5cs/t2535Hni/zKj3IfSFrZN3CVqgFbufpY7EBvrSIc2Su8dsn3vnUMI1GwHY 8yaEW14aDjUKqTu4JXZZhZ4V7X7DKQy4bAR2uPFRhPL9hTA+7SwjSQoK4FzCFgtsfb DfbEaO7PhGid6zaEGu4ZGmk+wtS/F9OYkL0JyOE6BioAE45s6qETt3uIEE7C7xT92P 41JHXORMB7sQQrtmQkYlIN1VUoQT2wFkG7pZSQq+57ePl0iJgvRNazEwxr1sDMrfOC pQGiAmu6CsIHQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 5602D180647 for ; Tue, 1 Jul 2025 07:39:32 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: * X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, FREEMAIL_REPLY,HTML_FONT_FACE_BAD,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from mail-pg1-f174.google.com (mail-pg1-f174.google.com [209.85.215.174]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 1 Jul 2025 07:39:32 +0000 (UTC) Received: by mail-pg1-f174.google.com with SMTP id 41be03b00d2f7-7fd35b301bdso3578577a12.2 for ; Tue, 01 Jul 2025 00:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1751355684; x=1751960484; darn=lists.php.net; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=x6gHRIAfYpL6HxjPAP4b6KYYmblwcLhhCFmc4SROqCY=; b=AlBI/Loj5Z4ygH6NRbdM+XAY0wHw4LzNv5wRh9sxgUZ7j0CkSekAGxmZ89FYVcXz/j 4SX4y9JaICjJHzE67oBHdub4JCExOojD8VlQjb1enl1OFePS7ltCMy8pmaxDz5EZyBkR Ta0uc6x5psShcGAmXSo2P+CkejLmuG8Wi2Z8TBhQoKGz306Gf00WAgN0MQ1ytxojrz0D KPCrhByutH6A5JxrTopf6fScmSH9tM7EtcIcVeX1Rqc19YTko9Z5+6cZ6U7dOwdaGe9x aGIKf61YNkwkHmWsXbVQP5GzF+IVOlcqNjpO3EQxdlpAc00QfMkQYLLk8DNBd5ow2edm 7tDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751355684; x=1751960484; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=x6gHRIAfYpL6HxjPAP4b6KYYmblwcLhhCFmc4SROqCY=; b=ljuakd77WTi6GsiWpXx2rb+H3rQWFIPRiRMVUct7DV82vGvZgYXyMAJtklCAaoOeyZ 6CRSNSxHWR9Y7oy4CZFg4ITe96SNJ5xpLflEsY46j8EhmsV1Tfh1CsHyLAvhkdmoGj3W /KhMYif0ICSRynMeN6VmmBUthxd1xtKl4M7FHtT82//0dhRq2yFcmhla3rBGuASgutSU bJ0C6PNuMZnFyDch4OJLv0TfMsXpeTmsNiGI4IX9b/Hru2w6bgqSsfPq6HN2QLsbgpmT EHu3VlwrpTenRHsdzkkhFJb/eeMr7go+k7Tiss4be9giACsmdjsS3hN1pVPSuE0PVrKV 7E9A== X-Forwarded-Encrypted: i=1; AJvYcCU4cRrUOvsRu0yEcCUkjse3fmimKOE+qevEax0qc6sqcwz9W1f4AzVQQb9NW0tGLRrFCDaCx34VNKk=@lists.php.net X-Gm-Message-State: AOJu0YzuW7pcrIiSG09DFkF4b4HBYWCy66km+jdYKGH45+qfRrMjN61q YleFXx8vEM79TGFgOy0iMBeTgEVokrSovBhiDbRUnjs6KfK4qwvrrcHhxycQM3vjvfPW+6C3Z6h 4rxvQk7JUmOeA7syVudHsz6jhUkhaRRA= X-Gm-Gg: ASbGnctvk+QmtA4RpKLRBL5Wy9Ec2Id0ebN9Xq4nut6PXEvmhjhF3/xmTlfAdOR+vzU tklJY03/MjIyp4Zbss3guel9tZHpADSKCnoU6gC/c7H/qlkT3zWlzKQVRa0OrDE3OlXA8NXQFjy 72boerssGQJiLE2EcFbNNAbm6esL54eOEEuL+OVIJgdaU= X-Google-Smtp-Source: AGHT+IGe6ymJS/d0/qBbSV3CgRM9ZVmIk4BpzenBwoWWfqbmpQPFsSKdFgr1JFDNOb52OwZHJtPzhJJz3z0zRX5NSvw= X-Received: by 2002:a17:90b:50cf:b0:314:7e4a:db08 with SMTP id 98e67ed59e1d1-318c9243f36mr27609346a91.18.1751355684212; Tue, 01 Jul 2025 00:41:24 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 1 Jul 2025 09:41:13 +0200 X-Gm-Features: Ac12FXxL99C3q1tHxcPxIxUZOcnECoGuecezPn-3BftAcUNWri3r6RuZoVVLHBc Message-ID: Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API To: Nicolas Grekas , PHP Internals List Content-Type: multipart/alternative; boundary="0000000000006ed25a0638d94551" From: nyamsprod@gmail.com (ignace nyamagana butera) --0000000000006ed25a0638d94551 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM ignace nyamagana butera < nyamsprod@gmail.com> wrote: > Thanks for the RFC! > > Here my doleance about it: > > - please make base58 part of the RFC - it's already widely used and havin= g > 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 Saf= e > 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 w= e > always go for the constant-time behavior? If not, what about defaulting t= o > 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 t= o > 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" mod= e > 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=E2=80=AFPM 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=C3=BCsterhus 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 defaulti= ng >> to constant-time, again, safe by default? >> - about DecodingMode, shouldn't this be Lenient by default, following th= e >> robustness principle? >> - (base85 looks great and would be nice to have also :) ) >> >> Cheers, >> Nicolas >> > --0000000000006ed25a0638d94551 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I have updated the RFC (https://wiki.php.net/rfc/da= ta_encoding_api) to include base58 encoding and decoding functions to t= he proposal with arguments in favor of the addition.

Best regards,

Ignace

On Fri, Jun 20, 2025 at 10:17=E2=80=AFAM ignace nyamagana butera <nyamsprod@gmail.com> wrote:
Thanks for the RFC!

Here my doleance about it:

- please make base58 part of the RFC - it's alre= ady widely used and having it implemented in C would be great. See=C2=A0http= s://github.com/php/php-src/issues/15195

I see = that there's already=C2=A0a PECL extension for base58. I will see what= =C2=A0I 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 th= e safe side by default

I went with the RFC recomme= ndation to set up the default. In case of Base64 the URL Safe variant is no= t the default. While we support URL safe variants there are plenty of appli= cations which do not expect the URL Safe variant, for instance, the data UR= Ls do not use the URL Safe variant.

- why do we ne= ed to decide between constant-time and unprotected? Can't we always go = for the constant-time behavior? If not, what about defaulting to constant-t= ime, again, safe by default?

In an ideal world I w= ould 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 Decoding= Mode, shouldn't this be Lenient by default, following the robustness pr= inciple?

I went with strict by default for securit= y 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, J= un 19, 2025 at 1:50=E2=80=AFPM Nicolas Grekas <nicolas.grekas+php@gmail.com= > wrote:
Hi Ignace

<= div dir=3D"ltr">

I'd like to start the discussion for a new RFC about adding=C2=A0R= FC 4648 compliant data encoding API

RFC proposal link:=C2=A0https://wiki.php.net/rfc/= data_encoding_api

If passed,=C2=A0T= im D=C3=BCsterhus has volunteered to do the implementation.

Thanks in advance for your remarks=C2=A0and comments.
=
Ignace Nyamagana Butera

Thanks for the RFC!

Here my= doleance about it:

- please make base58 part of t= he RFC - it's already widely used and having it implemented in C would = be great. See=C2=A0https://github.com/php/php-src/issues/15195
- it'd be great to default to url-safe base64. The RFC-compliant varia= nt is a very common risk, it'd be great to be on the safe side by defau= lt
- why do we need to decide between constant-time and unprotect= ed? Can't we always go for the constant-time behavior? If not, what abo= ut defaulting to constant-time, again, safe by default?
- about D= ecodingMode, shouldn't this be Lenient by default, following the robust= ness principle?
- (base85 looks great and would be nice to have a= lso :) )

Cheers,
Nicolas
--0000000000006ed25a0638d94551--