Re: Deprecating uniqid()

> On May 2, 2020, at 14:13, Ben Ramsey <ben@benramsey.com> wrote: > >> On May 2, 2020, at 13:57, AllenJB <php.lists@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

Attachment: [application/pgp-signature] Message signed with OpenPGP signature.asc