Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109974
Message-ID: <1004E13E-A005-4430-910D-B5430C492B58@benramsey.com>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_5BEC5B12-098C-4D02-B37B-5CA24604282F";
	protocol="application/pgp-signature";
	micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Sat, 2 May 2020 14:20:35 -0500
In-Reply-To: <C4580849-BC5B-45CA-9B57-56CB63B3F8F0@benramsey.com>
Cc: PHP Internals <internals@lists.php.net>
To: AllenJB <php.lists@allenjb.me.uk>
References: <9e3b1604-8d0a-9db4-aab6-e5f2198252f4@allenjb.me.uk>
 <C4580849-BC5B-45CA-9B57-56CB63B3F8F0@benramsey.com>
Subject: Re: [PHP-DEV] Deprecating uniqid()
From: ben@benramsey.com (Ben Ramsey)

--Apple-Mail=_5BEC5B12-098C-4D02-B37B-5CA24604282F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On May 2, 2020, at 14:13, Ben Ramsey <ben@benramsey.com> wrote:
>=20
>> On May 2, 2020, at 13:57, AllenJB <php.lists@allenjb.me.uk> wrote:
>>=20
>> Hi all,
>>=20
>> I'd like to discuss deprecating uniqid()
>>=20
>> 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).
>>=20
>> For older codebases that still rely on it, a userland replacement can =
be easily implemented (and could be published on Packagist).
>>=20
>> I noticed there was an RFC [0][1] brought up 2 years ago, but was =
never voted on. Does anyone know why this was?
>>=20
>> [0] https://externals.io/message/102097
>> [1] https://wiki.php.net/rfc/deprecate-uniqid
>>=20
>> Is there interest in deprecating this function?
>>=20
>> 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).
>=20
>=20
> 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=E2=80=99s 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


--Apple-Mail=_5BEC5B12-098C-4D02-B37B-5CA24604282F
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQToXQMR3fpbrPOmEOewLZeYnIwHGwUCXq3IAwAKCRCwLZeYnIwH
G/R/AP9UkgsdrJpd1kWp3VOlpkA5MIUFzP1rGLH2UY1Z+RjJ8wD/QGDAxaJWhHbs
dUjl+35sGtP0qJ4poK0DIk/3HS9A6qA=
=frim
-----END PGP SIGNATURE-----

--Apple-Mail=_5BEC5B12-098C-4D02-B37B-5CA24604282F--