Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124176
Message-ID: <5a2cd571-d681-4095-aa1b-be175f1778e9@varteg.nz>
Date: Tue, 2 Jul 2024 23:13:39 +1200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
To: internals@lists.php.net
References: <bw20I5b7ly3lSbI-2Bv3kfrfTVJbDo5RhwBiQa1PEwuLjprDJWptPajLiaialj1RLVKu7z1j0MofJUhhRVtzT_5i2E11oKeQx_VMUxnKhUE=@gpb.moe>
 <6683CDE4.7050607@adviesenzo.nl>
Content-Language: en-GB
In-Reply-To: <6683CDE4.7050607@adviesenzo.nl>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
From: weedpacket@varteg.nz (Morgan)

On 2024-07-02 21:52, Juliette Reinders Folmer wrote:
> Other than that, I join the previously voiced objections to the 
> deprecation of `uniqid()`, `md5()`, `sha1()`, `md5_file()`, `sha1_file()`.
> While I acknowledge that these functions _can_ be used inappropriately 
> for security-sensitive code, which should use alternative methods, these 
> functions have perfectly valid use-cases for non-security-sensitive code 
> and the impact of the BC-break of deprecating and eventually removing 
> these methods can, IMO, not be justified.

`md5()`, `sha1_file()` et al. are duplicated by `hash('md5')`, 
`hash_file('sha1')`, etc. These work in exactly the same way and produce 
exactly the same output as the dedicated functions and can be used just 
as appropriately or inappropriately.

Why, except in deference to their age, continue calling out MD5 and SHA1 
in particular for special consideration?



`uniqid()` doesn't have such an obvious translation (of the half-dozen 
alternatives in the RFC, the closest one is the first), but that's 
because its output isn't very good anyway: it doesn't even guarantee 
uniqueness.

The biggest effort in replacing it would come if you were relying on the 
main part[1] of its output being strictly increasing (which would be a 
mistake because it might not be).

[1] The main part is just a timestamp, extra entropy is provided by a 
call to random_bytes(4).



 > Keep in mind that while "we" know and understand that deprecations are
 > not errors, end-users often don't and particularly for open source
 > projects, this means that in practice these deprecations will need to be
 > addressed anyway to reduce the noise of users opening issues about them,
 > which without a clear path to removal of the functions, will, in a lot
 > of cases, mean adding the `@` operator to all uses.

Well, that's true of _any_ deprecation. Fortunately for these functions 
at least, clear paths for their removal are just that - clear.