> On May 2, 2020, at 14:13, Ben Ramsey <b...@benramsey.com> wrote: > >> On May 2, 2020, at 13:57, AllenJB <php.li...@allenjb.me.uk> wrote: >> >> Hi all, >> >> I'd like to discuss deprecating uniqid() >> >> I believe it's dangerously bad a doing "what it says on the tin". New >> developers still reach for it and do not read the warnings on the manual >> page (or if they do, don't fully understand how bad it is). >> >> For older codebases that still rely on it, a userland replacement can be >> easily implemented (and could be published on Packagist). >> >> I noticed there was an RFC [0][1] brought up 2 years ago, but was never >> voted on. Does anyone know why this was? >> >> [0] https://externals.io/message/102097 >> [1] https://wiki.php.net/rfc/deprecate-uniqid >> >> Is there interest in deprecating this function? >> >> If not deprecation, how could it be (further) "improved"? My first thought >> is to make the "more entropy" option enabled by default (the argument could >> remain so that it can be disabled by codebases that rely on the lower length >> and can take the tradeoffs). > > > Instead of deprecating and removing it, would anyone be opposed to replacing > the internals of the function so that it uses `random_bytes()` under the > hood, while all other functionality remains the same?
Of course, if we did this, it would break anyone’s ability to do this:
date('r', hexdec(substr(uniqid(), 0, 8)));
But I would argue that no one should be relying on these identifiers for
date/time purposes.
Cheers,
Ben
signature.asc
Description: Message signed with OpenPGP
