Hi On 6/25/24 17:49, Derick Rethans wrote:
These functions are indeed often used. The documentation for uniqid has some nice big warnings too. It can be used in situations, where it is OK.
Yes, the RFC acknowledges that.
Replacing the algorithm underneath uniqid can (and perhaps should) be looked at.
As explained in the RFC: The behavior is unfixable, because uniqid() is documented to be time-based. Changing the output format would be a much bigger breaking change than deprecating the function and letting users make an educated decision when choosing an alternative.
For the md5 and sha1 functions. Although these algorithms are not useful for "verifying the authenticity of a a payload", that doesn't mean they can't be used outside of that use case.
See my reply to Robert. The algorithms themselves are not going away. At least not as part of this RFC.
I understand the reasons why you want to "nudge" people to no longer use these "unsafe" functions, but IMO, in this case, it's not worth the BC issues.
For both uniqid() and the md5()/sha1() section, the RFC specifically acknowledges that there is a vast collection of code using it and for this reason specifically defines an indefinite deprecation period (with a guarantee that indefinite is at least 5 years / until PHP 10).
Please keep in mind that a deprecation is not an error, not a removal and not a change in behavior. Users will be able to migrate on their own pace and for both uniqid() and md5()/sha1() there is a drop-in replacement provided in the RFC that is guaranteed to work with PHP 7.4+.
Best regards Tim Düsterhus
