Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124432
Feedback-ID: ifab94697:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-568-g843fbadbe-fm-20240701.003-g843fbadb
Precedence: bulk
MIME-Version: 1.0
Message-ID: <af9e728a-5961-4f90-85f9-f03b397fe837@app.fastmail.com>
In-Reply-To: 
 <3XlxyoEWXN5MLqWhlh4uQMXGc2DRs7OH72f_InABxrhsBVTZIPOrfO3qEKqG94844M2r3FUS_zGMa60dENgvLP6TC8zOWZASkN6w6ZxsaxM=@gpb.moe>
References: 
 <bw20I5b7ly3lSbI-2Bv3kfrfTVJbDo5RhwBiQa1PEwuLjprDJWptPajLiaialj1RLVKu7z1j0MofJUhhRVtzT_5i2E11oKeQx_VMUxnKhUE=@gpb.moe>
 <6683CDE4.7050607@adviesenzo.nl>
 <Skh-IB3l7OxslclNZdB5ZE3G5PaIvpoz3iojK10noNbXkj1odNNvzI5w7X1aSj7IKZ951646yQ8IrUW_wNaQuv94NB0jo3IXlFImcpu_hxc=@gpb.moe>
 <668B5728.40300@adviesenzo.nl>
 <3XlxyoEWXN5MLqWhlh4uQMXGc2DRs7OH72f_InABxrhsBVTZIPOrfO3qEKqG94844M2r3FUS_zGMa60dENgvLP6TC8zOWZASkN6w6ZxsaxM=@gpb.moe>
Date: Mon, 15 Jul 2024 16:12:47 +0200
To: "Gina P. Banyard" <internals@gpb.moe>,
 "Juliette Reinders Folmer" <php-internals_nospam@adviesenzo.nl>
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
Content-Type: multipart/alternative;
 boundary=22413b32aa824842b6cd4b3efa621bd9
From: rob@bottled.codes ("Rob Landers")

--22413b32aa824842b6cd4b3efa621bd9
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Mon, Jul 15, 2024, at 13:20, Gina P. Banyard wrote:
> On Monday, 8 July 2024 at 04:04, Juliette Reinders Folmer <php-interna=
ls_nospam@adviesenzo.nl> wrote:
> > On 2-7-2024 20:05, Gina P. Banyard wrote:
> >> On Tuesday, 2 July 2024 at 10:52, Juliette Reinders Folmer <php-int=
ernals_nospam@adviesenzo.nl> wrote:
> >>
> >>> * While a number of proposals include an impact analysis (thank yo=
u!), a significant number of the proposals don't.
> >>> It would be appreciated if for those proposals which aren't removi=
ng unused/unusable functionality, some sort of impact analysis was added.
> >>
> >> You will need to clarify which ones you are talking about.
>  ... snip big ...
>=20
> > I also don't agree that there are "more appropriate replacements ava=
ilable".
> > The suggested `hash()` replacements for the md5/sha1* functions have=
 the exact same functionality, which the RFC considers "incorrect use", =
so what are we actually solving by this deprecation ? Devs not having en=
ough to do already ?
> > The problem (for open source) with "force-replacing" the uses of `md=
5/sha1*` functions with the `hash` function calls, is that the hash exte=
nsion was not part of PHP core until PHP 7.4, which means that for a sig=
nificant number of open source projects, the replacement is not a one-on=
-one function call replacement, but needs guard code for PHP < 7.4 in ca=
se the hash extension is not available.
>=20
> Reiterating what I said previously, replacing it with the one-to-one e=
quivalent should only be done if you truly need those specific algorithm=
s.
> Otherwise its usage should be reconsidered depending on the requiremen=
ts and switched to something "safer".
> Hopefully this is clearer now that Tim amended the RFC.

This always gets me. "safer" doesn't have a consistent meaning. For exam=
ple, if you were to want to create a "content addressable address" using=
 a hash and it needs to fit inside a 128 bit number (such as a GUID), yo=
u may be tempted to take SHA-X and just truncate it. However, this biase=
s the resulting numbers, which this bias may be considered unsafe (such =
as using it in an A/B testing tool). Just because you have a short hash,=
 doesn't make it "unsafe" as longer hashes can also be considered "unsaf=
e." What people usually mean by this is in the context of encryption, an=
d in those cases it is unsafe, but in the context of non-encryption, usa=
ge of truncated larger hashes is just as unsafe.

=E2=80=94 Rob
--22413b32aa824842b6cd4b3efa621bd9
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}
p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div><br></div>=
<div><br></div><div>On Mon, Jul 15, 2024, at 13:20, Gina P. Banyard wrot=
e:<br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div><span>On=
 Monday, 8 July 2024 at 04:04, Juliette Reinders Folmer &lt;<a target=3D=
"_blank" rel=3D"noreferrer nofollow noopener" href=3D"mailto:php-interna=
ls_nospam@adviesenzo.nl">php-internals_nospam@adviesenzo.nl</a>&gt; wrot=
e:</span><br></div><div><span>&gt; On 2-7-2024 20:05, Gina P. Banyard wr=
ote:</span><br></div><div><span>&gt;&gt; On Tuesday, 2 July 2024 at 10:5=
2, Juliette Reinders Folmer &lt;<a target=3D"_blank" rel=3D"noreferrer n=
ofollow noopener" href=3D"mailto:php-internals_nospam@adviesenzo.nl">php=
-internals_nospam@adviesenzo.nl</a>&gt; wrote:</span><br></div><div><spa=
n>&gt;&gt;</span><br></div><div><span>&gt;&gt;&gt; * While a number of p=
roposals include an impact analysis (thank you!), a significant number o=
f the proposals don't.</span><br></div><div><span>&gt;&gt;&gt; It would =
be appreciated if for those proposals which aren't removing unused/unusa=
ble functionality, some sort of impact analysis was added.</span><br></d=
iv><div><span>&gt;&gt;</span><br></div><div><span>&gt;&gt; You will need=
 to clarify which ones you are talking about.</span><br></div><div>&nbsp=
;... snip big ...<br></div><div><br></div><div><span>&gt; I also don't a=
gree that there are "more appropriate replacements available".</span><br=
></div><div><span>&gt; The suggested `hash()` replacements for the md5/s=
ha1* functions have the exact same functionality, which the RFC consider=
s "incorrect use", so what are we actually solving by this deprecation ?=
 Devs not having enough to do already ?</span><br></div><div><span>&gt; =
The problem (for open source) with "force-replacing" the uses of `md5/sh=
a1*` functions with the `hash` function calls, is that the hash extensio=
n was not part of PHP core until PHP 7.4, which means that for a signifi=
cant number of open source projects, the replacement is not a one-on-one=
 function call replacement, but needs guard code for PHP &lt; 7.4 in cas=
e the hash extension is not available.</span><br></div><div><br></div><d=
iv><span>Reiterating what I said previously, replacing it with the one-t=
o-one equivalent should only be done if you truly need those specific al=
gorithms.</span><br></div><div><span>Otherwise its usage should be recon=
sidered depending on the requirements and switched to something "safer".=
</span><br></div><div><span>Hopefully this is clearer now that Tim amend=
ed the RFC.</span><br></div></blockquote><div><br></div><div>This always=
 gets me. "safer" doesn't have a consistent meaning. For example, if you=
 were to want to create a "content addressable address" using a hash and=
 it needs to fit inside a 128 bit number (such as a GUID), you may be te=
mpted to take SHA-X and just truncate it. However, this biases the resul=
ting numbers, which this bias may be considered unsafe (such as using it=
 in an A/B testing tool). Just because you have a short hash, doesn't ma=
ke it "unsafe" as longer hashes can also be considered "unsafe." What pe=
ople usually mean by this is in the context of encryption, and in those =
cases it is unsafe, but in the context of non-encryption, usage of trunc=
ated larger hashes is just as unsafe.<br></div><div><br></div><div id=3D=
"sig121229152">=E2=80=94 Rob<br></div></body></html>
--22413b32aa824842b6cd4b3efa621bd9--