Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:127730 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 500121A00CD for ; Fri, 20 Jun 2025 08:17:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1750407349; bh=bsXU9Vpvne9KaQHE3IfzvFKP0NvRzwV4K0ZJvuCZx3g=; h=References:In-Reply-To:From:Date:Subject:To:From; b=CfyipS2Emebh6Z9TOvRerQiE1EMU2GVhWtPBXnECAGFMlH2aPvh2TJKAClTsZrlgO yMJckdQ0Trq80anykNP9LJJTWjj4YrhvvA/2jiqTKvQLF+ZJ85eOeXBfNjcrQH8um4 zlQ4BDr29CS92Vrv6hVJSj290eB+fWqFBPP91JIHDSRra9yfXRsLiIbqf7kkYqmLyR gk9uVEv2p3QQuTei8mowyUSv4oVBSeDMTrjyXX7UrlHGGF8bwEms0JEmYM+wBuCDSR 2j35GKO7xProO9XJvKFfDvY1xSjYQBWbAR+SjzBavkfLmIwM3nRQN4GgT4A4GUGeTW xwGGGoLV7p3pA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id CA1B81801E0 for ; Fri, 20 Jun 2025 08:15:46 +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-f173.google.com (mail-pg1-f173.google.com [209.85.215.173]) (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 ; Fri, 20 Jun 2025 08:15:44 +0000 (UTC) Received: by mail-pg1-f173.google.com with SMTP id 41be03b00d2f7-b2c4331c50eso1262868a12.3 for ; Fri, 20 Jun 2025 01:17:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750407460; x=1751012260; 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=bsXU9Vpvne9KaQHE3IfzvFKP0NvRzwV4K0ZJvuCZx3g=; b=Lons4n4oawW3jPMtrbKCLZy4TEZTG0qMwcj3D+9ls8WYVTZ0mbdz5bXOYT7G1algXw 4VRqxWWmv4ZdTSr7tF9r0C9psVrPCOnifXGu9qJo/geWYNnQteY7IOnqK0wVQ+ZSinBy Mydqe5ChAeg/XGpMEhOop1ob+h9+gpOTDuZhzV6vy2C41KQp6qzs3qObhatSEeJENZFg eqg5NsFwaCJXQDVrbC5b/4IfyGOoBMMvtSbAbS0rnX4WpmUAX9rdN2N7DAXAHflYJ2g6 arFDEc6PNUCZWsZxC++yF6MR4PZ8tgjOWcViTVh1fjTACLecsCSCSiryQl0yl+vyqYxV 9Mfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750407460; x=1751012260; 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=bsXU9Vpvne9KaQHE3IfzvFKP0NvRzwV4K0ZJvuCZx3g=; b=J6lcEcV2cghNg9ZAjVpNZBeAwOUjdCZ4bKoiF2NqKBTnezAOoPYf5/IYVmELraEm40 GDuJKIGWzY+v02CU8sf22KJ8YGqXrTmZ7nq/SUL9wc6LYw4KqRUvtls7gr5XLv9R6qNY +WMLb9rjXYkfAXjlHj8ATUdt9XldzrcFtdyXbv6DtPtsPEBlxo4tpPGWo/3U2zYtt2E9 xcANZzlUo5Zb1P66Nv/DKaCiv+yYJ8nNp1HAULqWMRdUCRx2J/vM63FQzfDCMRRCMfy/ G2T2N4a84m/bqjdh+pwUD3Xm5ABeCG55L6UTg1OzQNW8CBK6NytGasBMp+krxARHW1C0 UVqA== X-Forwarded-Encrypted: i=1; AJvYcCXE0CscVHTN3V7L82n2yK59JcE6FsDWDy7px/6qQ7NF1lckbM2k3mCMbgN3l/idh9DR/eGw6Rts9QQ=@lists.php.net X-Gm-Message-State: AOJu0YyXSIS0NvcTnX5KLMbWi83yta1fd1X7RHH5fG/i13pmNFBCk48L 8UXFbtEU2I6Hh6+EIg2EMjdZUDVI4WZ/xu1nG3ZB3EppUdBF0Ioq3EbR9WM6A2+8bjwGtQa8vGK ebRXvB9i1FoOvHWF0W3s7IVtai7Vh3eY0u1FB X-Gm-Gg: ASbGnctgPQFjHilYsjp6kizHnhad+D9U23hUzrthdW68Ue0Yjnx8ZbAKLUXQDN5B0xZ bZA1uYCcL+8z8umgVC+i2rKmGftnhNepz0g4rN/Y3mqJ7oYqV/gaps7B4zdpKVzUvJgmv58J/cd R+mzC+jgDdYbjYqLz7DkTAxnJASQEUb3R+Ml03KrKyELsP3PTncq/fXrOTeV2K4Pdo8LDCgRq9U Qh+ X-Google-Smtp-Source: AGHT+IEyU/7zYlklNg5KmfSLUkAL3R/b2DR0bBjZJb2YRVyLdyWGHrzZ3CBBi5JttAZew1SDlfwTOPjpLsMZXyPf0zA= X-Received: by 2002:a17:90b:2d8e:b0:311:c5d9:2c70 with SMTP id 98e67ed59e1d1-3159d67fea5mr3707997a91.15.1750407460405; Fri, 20 Jun 2025 01:17:40 -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: Fri, 20 Jun 2025 10:17:28 +0200 X-Gm-Features: AX0GCFsiG_rPIzYKil4jRKnkrdPLCUZuobqVI48P_w8-bhvOwpqhUux86pQwdVI 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="000000000000e3c92c0637fc7e80" From: nyamsprod@gmail.com (ignace nyamagana butera) --000000000000e3c92c0637fc7e80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Nicolas Grekas 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 havin= g > 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 w= e > always go for the constant-time behavior? If not, what about defaulting t= o > 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 > --000000000000e3c92c0637fc7e80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the RFC!

Here my = doleance about it:

- please make base58 part of th= e RFC - it's already widely used and having it implemented in C would b= e great. See=C2=A0https://github.com/php/php-src/issues/15195
=
I see that there's already=C2=A0a PECL extension for bas= e58. 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 the safe side by default

I went = with the RFC recommendation to set up the default. In case of Base64 the UR= L 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 i= nstance, 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 defa= ulting to constant-time, again, safe by default?

I= n 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 ever= y scenario hence why I went defensive on this option.

<= div>- about DecodingMode, shouldn't this be Lenient by default, followi= ng the robustness principle?

I went with strict by= default for security reasons. The Lenient behavior described is for instan= ce more restrictive than the current "lenient" mode used by the c= urrent 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 Ni= colas Grekas <nicolas.= grekas+php@gmail.com> wrote:
Hi Ignace

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

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

If passed,=C2=A0Tim D=C3=BCsterhus has volunteered to do the imple= mentation.

Thanks in advance for your remarks=C2=A0and c= omments.

Best regards,
Ignace Nyamagana Butera

Thanks for the RFC!
<= div>
Here my doleance about it:

- pl= ease make base58 part of the 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 base6= 4. 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 c= onstant-time and unprotected? Can't we always go for the constant-time = behavior? If not, what about defaulting to constant-time, again, safe by de= fault?
- about DecodingMode, shouldn't this be Lenient by def= ault, following the robustness principle?
- (base85 looks great a= nd would be nice to have also :) )

Cheers,
Nicolas
--000000000000e3c92c0637fc7e80--