> On Jul 27, 2024, at 8:36 AM, Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> > wrote: > On 27 July 2024 00:58:17 BST, Morgan <weedpac...@varteg.nz> wrote: >> >> 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. > > I understand what is being claimed (and you're not the only one claiming it), > I'm just not convinced it's true. I think they have standalone functions for > the same reason we added str_contains and str_starts_with - because it's > convenient to have straightforward functions for common use cases. > > The hash() function is like a 60-piece set of interchangeable screwdriver > heads, which only professionals and enthusiasts need; md5() and sha1() are > like the flat-head and Phillips screwdrivers that everyone has in a drawer > somewhere. > > The thing that always surprises me is that PHP *doesn't* have a standalone > function for SHA-256, which is the only other I've ever used. > > To continue the analogy, we're missing a Pozidriv screwdriver, so people are > misusing the Phillips one. The RFC is suggesting that we take away their > flat-head and Phillips screwdrivers, and leave them with the 60-piece set, > and no instructions. > > My suggestion is we instead give them a Pozidriv screwdriver, and write some > tips on how to use it correctly.
I rise in support of this mindset. Some of us like to draw inspiration from other languages, and in that vein one of the things that makes Go such a joy to program in is the fact the Go team continues to add "convenience" functions with every new 6 month release. Many (all?) of the functions the Go team adds could have been written in "userland" but they represent such common use-cases that the Go team decided to make them easy and obvious. They even soft deprecate functions and structs that are not ideal and replace them with ones with better names and better signatures. If Go had started with the string and array functions PHP has today they would almost certainly replaced them by now, ~15 years into Go's tenure. It is a shame that PHP's culture is so hostile towards adding functionality that could also be added in userland, especially when that functionality would simplify and standardize algorithms that are non-obvious and/or too easy to implement incorrectly. If the PHP culture embraced moving common use-cases into core it would make PHP much more pleasurable to program in and make it much less likely that PHP programs would have bugs and/or security vulnerabilities. > On Jul 27, 2024, at 6:14 PM, Morgan <weedpac...@varteg.nz> wrote: > Why a SHA2 algorithm? Why not a SHA3 one? How about standalone functions for > both, and then when SHA4 comes along (as it inevitably will) another > standalone function for one of its variants? Yes. Yes, And Yes. And ideally within a `\PHP` namespace. -Mike P.S. But as we know a standardized `\PHP` namespace is apparently never going to happen although for the life of me I still cannot understand why not — and I was here during the voting down of that RFC ~4 years ago — given how so many other languages had done the equivalent.
