Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124670
Message-ID: <2b931735-d8ed-4146-8e24-d76c2fa82d06@varteg.nz>
Date: Mon, 29 Jul 2024 13:19:20 +1200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4
To: internals@lists.php.net
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>
 <F791876D-1A33-4DB7-938A-DEC048493D87@rwec.co.uk>
Content-Language: en-GB
In-Reply-To: <F791876D-1A33-4DB7-938A-DEC048493D87@rwec.co.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
From: weedpacket@varteg.nz (Morgan)

On 2024-07-28 18:42, Rowan Tommins [IMSoP] wrote:
> 
> 
> On 27 July 2024 23:14:32 BST, Morgan <weedpacket@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?
> 
> You tell me. As I have repeatedly said, I don't actually know anything about these algorithms. SHA-256 is the only one on the list which I've heard of, and I'm aware it's newer than SHA-1. I don't know why SHA-512 isn't "better", I don't know why nobody talks about SHA-3, and I don't know if one of the others in the list is absolutely amazing and should be everyone's default forever.
> 
> As far as I can see, nobody, in this whole discussion, has actually stepped up and explained what users should be using, once we have taught them that MD5 and SHA-1 are bad.
> 
> 
>> Or leave them them the 60-piece set (which includes flat-head and Phillips screwdrivers, so they're not being taken away), and write some tips on how to use it correctly.
> 
> So go ahead and write those tips. You don't need an RFC vote to improve the documentation.
> 
> 
> Here is my offer to those arguing in favour of this deprecation: If you show me a draft of a comprehensive improvement to the manual to explain how users should be choosing a hashing algorithm, I will consider changing my vote.
> 
> I am also happy to help with proofreading, and working out how to format it into DocBook that fits nicely in the manual.
> 
> As long as the deprecation rests on "somebody in the next 10 years might get round to improving the manual", my vote remains a firm No.
> 
> 
> Regards,
> Rowan Tommins
> [IMSoP]

Hey, all I'm doing is pointing out that the only reason those functions 
were standalone to start with is because when they were added they were 
the only ones around; they weren't introduced as "easier to use" 
alternatives to the more generic case. If hash() had been added in PHP 
with half a dozen different algorithms right at the beginning, would 
md5() and sha1() have been given special treatment? Possibly: MD5 (and 
later SHA1) got all the publicity at the time.

Whether they are "bad" or "should not be used" has nothing to do with 
that. I understand that the RFC is hard on them because they are broken 
algorithms that don't have any advantages over others that have been 
added since and therefore the language shouldn't be encouraging their 
use by providing dedicated functions for them, I'm just pointing out 
that those dedicated functions are historical artefacts.

I haven't seen an explanation of what makes them "easier to use": if you 
want to use md5() (for whatever reason: I don't care) it's not that hard 
to write hash("md5") instead. I just went through a file deduplication 
utility of mine and did exactly that. Yes, I am using MD5 as a message 
digest algorithm.