Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124702
Feedback-ID: id5114917:Fastmail
Message-ID: <9cdc0881-77dd-447d-8bc1-e572a7572db5@rwec.co.uk>
Date: Wed, 31 Jul 2024 22:38:33 +0100
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>
 <31ef5c07-b472-431b-9214-f4a9c23080d4@bastelstu.be>
Content-Language: en-GB
In-Reply-To: <31ef5c07-b472-431b-9214-f4a9c23080d4@bastelstu.be>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 30/07/2024 21:57, Tim Düsterhus wrote:
> Let me attempt to give an explanation. As of today users should use in 
> order of priority:
>
> 1. The hash function they need for interoperability: If a service 
> provides a SHA-1 checksum, then there is no choice and SHA-1 needs to 
> be used.
> 2. The hash function their security team requests them to use.
> 3. A function from the SHA-2 family, with SHA-256 being a good default 
> choice, because that's the secure default choice across the industry. 


Thanks, this is a good concise explanation, and exactly the kind of 
thing I think should be in the documentation *before* we start telling 
people they're "doing it wrong" by using md5() or sha1().

It also strengthens my conviction that we should add sha256() and 
sha256_file() as standalone functions: a "good default choice" is really 
all most users want or need. There seems to be no risk of us needing to 
add a new function every other year, or provide a dozen functions to 
cover different use cases.

Users in scenarios 1 or 2 will know what to look up in the hash_algos() 
list and pass to hash(). Users who have complex use cases like 
incremental hashing, or whatever hash_hkdf() does, can keep using the 
complex but flexible functions that provide those facilities.


Note that if SHA-256 ever stops being the recommendation, having a 
sha256() function will give us the same opportunity we have now with 
md5() and sha1(): to issue a message to users of the standalone 
function, but keep the algorithm fully available in hash().


Regards,

-- 
Rowan Tommins
[IMSoP]