On 2024-07-26 09:34, Rowan Tommins [IMSoP] wrote:
On 24/07/2024 23:01, Morgan wrote:
And they would still be available as hash("md5") and hash("sha1"); the
only reason they're called out as their own distinct functions today
is historical inertia.
I don't agree that the reasons for including standalone functions are
"historical". The RFC itself gives a good reason for having such functions:
By "historical" I mean just md5() was in PHP in version 3, sha1() was
added in 4.3, and hash() (via PECL) in 5.1.2. md5(), md5_file(), sha1(),
and sha1_file() could have been deprecated when hash() became a core PHP
extension in version 7, and now (or when looking at targeting 9) would
have been about when we'd be discussing removing them.
I'm not talking about the MD5 or SHA1 algorithms or whether 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 were created.
Why do they get this special treatment today?
(PS: crc32b also implemented via hash() as well as having its own function.)
A new user being told "don't use sha1(), use hash() and pick from this
list" is more likely to say "ah, there's sha1, jolly good" than spend an
afternoon reading cryptography journals. There's no pit of success to
fall into.
A new user skimming through the list of string functions is likely to
see see "md5()" there and think "ah, there's a hash function, jolly good".
