Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124655
Feedback-ID: ifab94697:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-582-g5a02f8850-fm-20240719.002-g5a02f885
Precedence: bulk
MIME-Version: 1.0
Message-ID: <ab8c974a-c31c-4ff6-974d-0a8c962d5e22@app.fastmail.com>
In-Reply-To: <0824789d-0e36-4628-85c1-4b8d9b7f86af@varteg.nz>
References: 
 <USzt7tZZlO1DmAbSTLhD-bqa23FqZn0zk2aah8Ndxgk9c7RY5PefQ8MjbYPUYAzr2_m4Cf-5AI4PuNBTS84rim_FNS6RaT-cWSv714HEvvU=@gpb.moe>
 <1a88918e-e808-d778-45e1-53797660e093@php.net>
 <CAPrKfG5Cw_nU7g7FR+t4C1-YZ8CDsDO_-sRs=yEsHO5kCTZL+A@mail.gmail.com>
 <c03eb187-bd21-4a4b-9faf-8d0243eaa994@varteg.nz>
 <aa6bc7aa-28d9-40ca-974f-65075adb6199@rwec.co.uk>
 <3563cf9b-8eab-4c82-b525-a5d2f9a767bb@varteg.nz>
 <38920A4B-790D-48C7-B2F6-C49D3F506232@rwec.co.uk>
 <0824789d-0e36-4628-85c1-4b8d9b7f86af@varteg.nz>
Date: Sun, 28 Jul 2024 00:25:49 +0200
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4
Content-Type: multipart/alternative;
 boundary=41d4c3efa74a43ddac0a915b3ed20108
From: rob@bottled.codes ("Rob Landers")

--41d4c3efa74a43ddac0a915b3ed20108
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Sun, Jul 28, 2024, at 00:14, Morgan wrote:
> On 2024-07-28 00:36, Rowan Tommins [IMSoP] wrote:
> >=20
> >=20
> > On 27 July 2024 00:58:17 BST, Morgan <weedpacket@varteg.nz> wrote:
> >>
> >> I'm not talking about the MD5 or SHA1 algorithms or whether they sh=
ould or shouldn't be used. I'm just talking about the functions themselv=
es. md5(), md5_file(), sha1(), and sha1_file(). They only exist because =
there wasn't the generic hash algorithm extension when they were created.
> >=20
> > I understand what is being claimed (and you're not the only one clai=
ming it), I'm just not convinced it's true.
>=20
> I'm just looking at the manual's version information about when the=20
> functions were introduced. Seems pretty unambiguous: md5, sha1, hash:=20
> versions 3, 4, and 5 (via PECL).
>=20
> > I think they have standalone functions for the same reason we added=20
> str_contains and str_starts_with - because it's convenient to have=20
> straightforward functions for common use cases.
> >=20
> Because there weren't any purpose-built functions that did the job,=20
> forcing users to use other functions in expensive ways for what is=20
> internally a pretty simple task. There is a purpose-built function for=20
> hashing.
>=20
> > The hash() function is like a 60-piece set of interchangeable screwd=
river heads, which only professionals and enthusiasts need; md5() and sh=
a1() are like the flat-head and Phillips screwdrivers that everyone has =
in a drawer somewhere.
> >=20
> > The thing that always surprises me is that PHP *doesn't* have a stan=
dalone function for SHA-256, which is the only other I've ever used.
> >=20
>=20
> Why a SHA2 algorithm? Why not a SHA3 one? How about standalone functio=
ns=20
> for both, and then when SHA4 comes along (as it inevitably will) anoth=
er=20
> standalone function for one of its variants?
>=20
>=20
> > To continue the analogy, we're missing a Pozidriv screwdriver, so pe=
ople are misusing the Phillips one. The RFC is suggesting that we take a=
way their flat-head and Phillips screwdrivers, and leave them with the 6=
0-piece set, and no instructions.
> >=20
> > My suggestion is we instead give them a Pozidriv screwdriver, and wr=
ite some tips on how to use it correctly.
> >=20
> Or leave them them the 60-piece set (which includes flat-head and=20
> Phillips screwdrivers, so they're not being taken away), and write som=
e=20
> tips on how to use it correctly.
>=20
> > Regards,
> > Rowan Tommins
> > [IMSoP]
>=20

I'd love to see a "hashing" namespace and all of these given their own f=
unctions with docblocks and manual pages instead of the current generic =
"god of hash" page which doesn't even list the hash functions available;=
 you have to click on hash_algos and then look at the var_dump of hash a=
lgorithms. From there, you can google each one and try to understand wha=
t each one is good at and why you would use murmur3a over murmer3f, then=
 try to figure out which one is the version that is compatible with java=
script but not compatible with c# or maybe the other way around... (I re=
cently got to go on that ride).

If we are going to deprecate the standalone functions (see the sha1 page=
, which at least links to a page about the sha1 algorithm, or the md5 rf=
c, which links to the md5 rfc) we should seriously invest in documenting=
 these hashing algorithms and explaining them. In the very least, link t=
o their respective RFCs.

=E2=80=94 Rob
--41d4c3efa74a43ddac0a915b3ed20108
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}</style></head><body><div>On Sun, Jul 28,=
 2024, at 00:14, Morgan wrote:<br></div><blockquote type=3D"cite" id=3D"=
qt" style=3D""><div>On 2024-07-28 00:36, Rowan Tommins [IMSoP] wrote:<br=
></div><div>&gt;&nbsp;<br></div><div>&gt;&nbsp;<br></div><div>&gt; On 27=
 July 2024 00:58:17 BST, Morgan &lt;<a href=3D"mailto:weedpacket@varteg.=
nz">weedpacket@varteg.nz</a>&gt; wrote:<br></div><div>&gt;&gt;<br></div>=
<div>&gt;&gt; I'm not talking about the MD5 or SHA1 algorithms or whethe=
r they should or shouldn't be used. I'm just talking about the functions=
 themselves. md5(), md5_file(), sha1(), and sha1_file(). They only exist=
 because there wasn't the generic hash algorithm extension when they wer=
e created.<br></div><div>&gt;&nbsp;<br></div><div>&gt; I understand what=
 is being claimed (and you're not the only one claiming it), I'm just no=
t convinced it's true.<br></div><div><br></div><div>I'm just looking at =
the manual's version information about when the&nbsp;<br></div><div>func=
tions were introduced. Seems pretty unambiguous: md5, sha1, hash:&nbsp;<=
br></div><div>versions 3, 4, and 5 (via PECL).<br></div><div><br></div><=
div>&gt; I think they have standalone functions for the same reason we a=
dded&nbsp;<br></div><div>str_contains and str_starts_with - because it's=
 convenient to have&nbsp;<br></div><div>straightforward functions for co=
mmon use cases.<br></div><div>&gt;&nbsp;<br></div><div>Because there wer=
en't any purpose-built functions that did the job,&nbsp;<br></div><div>f=
orcing users to use other functions in expensive ways for what is&nbsp;<=
br></div><div>internally a pretty simple task. There is a purpose-built =
function for&nbsp;<br></div><div>hashing.<br></div><div><br></div><div>&=
gt; The hash() function is like a 60-piece set of interchangeable screwd=
river heads, which only professionals and enthusiasts need; md5() and sh=
a1() are like the flat-head and Phillips screwdrivers that everyone has =
in a drawer somewhere.<br></div><div>&gt;&nbsp;<br></div><div>&gt; The t=
hing that always surprises me is that PHP *doesn't* have a standalone fu=
nction for SHA-256, which is the only other I've ever used.<br></div><di=
v>&gt;&nbsp;<br></div><div><br></div><div>Why a SHA2 algorithm? Why not =
a SHA3 one? How about standalone functions&nbsp;<br></div><div>for both,=
 and then when SHA4 comes along (as it inevitably will) another&nbsp;<br=
></div><div>standalone function for one of its variants?<br></div><div><=
br></div><div><br></div><div>&gt; To continue the analogy, we're missing=
 a Pozidriv screwdriver, so people are misusing the Phillips one. The RF=
C is suggesting that we take away their flat-head and Phillips screwdriv=
ers, and leave them with the 60-piece set, and no instructions.<br></div=
><div>&gt;&nbsp;<br></div><div>&gt; My suggestion is we instead give the=
m a Pozidriv screwdriver, and write some tips on how to use it correctly=
.<br></div><div>&gt;&nbsp;<br></div><div>Or leave them them the 60-piece=
 set (which includes flat-head and&nbsp;<br></div><div>Phillips screwdri=
vers, so they're not being taken away), and write some&nbsp;<br></div><d=
iv>tips on how to use it correctly.<br></div><div><br></div><div>&gt; Re=
gards,<br></div><div>&gt; Rowan Tommins<br></div><div>&gt; [IMSoP]<br></=
div><div><br></div></blockquote><div><br></div><div>I'd love to see a "h=
ashing" namespace and all of these given their own functions with docblo=
cks and manual pages instead of the current generic "god of hash" page w=
hich doesn't even list the hash functions available; you have to click o=
n hash_algos and then look at the var_dump of hash algorithms. From ther=
e, you can google each one and try to understand what each one is good a=
t and why you would use murmur3a over murmer3f, then try to figure out w=
hich one is the version that is compatible with javascript but not compa=
tible with c# or maybe the other way around... (I recently got to go on =
that ride).<br></div><div><br></div><div>If we are going to deprecate th=
e standalone functions (see the sha1 page, which at least links to a pag=
e about the sha1 algorithm, or the md5 rfc, which links to the md5 rfc) =
we should seriously invest in documenting these hashing algorithms and e=
xplaining them. In the very least, link to their respective RFCs.</div><=
div><br></div><div id=3D"sig121229152">=E2=80=94 Rob<br></div></body></h=
tml>
--41d4c3efa74a43ddac0a915b3ed20108--