Please, no top posting.
On Tue, 25 Jun 2024, Marco Pivetta wrote:
I agree with most of these deprecations, except:
* `uniqid()`, in my case (XKCD 1172) is largely used for quickly
generating a semi-random string for test purposes: a suitable replacement
PRNG implementation would be welcome. Even refactoring with tools like
Rector will lead to quite messy code, or added dependencies. IMO fine to
get rid of **this specific implementation**, if a safe function is
provided, such as `random_ascii_string()` or such (dunno, just a hint)
* `md5()`, `sha1()` - OK-ish with moving to `hash('<algo>', ...)`, but
while these are insecure for most use-cases, they are part of the domain of
many tools, including GIT itself. I can Rector my way out of it, just not
sure these should be hidden into `hash(...)`
I agree on both points.
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.
Replacing the algorithm underneath uniqid can (and perhaps should) be
looked at.
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.
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.
cheers,
Derick
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