Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109975
MIME-Version: 1.0
References: <9e3b1604-8d0a-9db4-aab6-e5f2198252f4@allenjb.me.uk> <C4580849-BC5B-45CA-9B57-56CB63B3F8F0@benramsey.com>
In-Reply-To: <C4580849-BC5B-45CA-9B57-56CB63B3F8F0@benramsey.com>
Date: Sat, 2 May 2020 21:58:07 +0200
Message-ID: <CAF+90c-Uc1_F0Yy-kXvspCsLumAbOLfY-G_in3TTE288f=ZTrw@mail.gmail.com>
To: Ben Ramsey <ben@benramsey.com>
Cc: AllenJB <php.lists@allenjb.me.uk>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000069e0e405a4afb8e9"
Subject: Re: [PHP-DEV] Deprecating uniqid()
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000069e0e405a4afb8e9
Content-Type: text/plain; charset="UTF-8"

On Sat, May 2, 2020 at 9:13 PM 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?
>

I believe this has been discussed in the past, and the basic problem is
that uniqid() currently only returns 13 hex characters, so we can encode at
most 52 bits of entropy without changing the output format. This is
insufficient. Changing the format could break assumptions, such as database
column sizes.

Personally, I would be in favor of deprecating the function. I've run into
an issue caused by non-unique uniqid() somewhat recently myself as well.

Regards,
Nikita

--00000000000069e0e405a4afb8e9--