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.
