Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109976
MIME-Version: 1.0
References: <9e3b1604-8d0a-9db4-aab6-e5f2198252f4@allenjb.me.uk>
 <C4580849-BC5B-45CA-9B57-56CB63B3F8F0@benramsey.com> <CAF+90c-Uc1_F0Yy-kXvspCsLumAbOLfY-G_in3TTE288f=ZTrw@mail.gmail.com>
In-Reply-To: <CAF+90c-Uc1_F0Yy-kXvspCsLumAbOLfY-G_in3TTE288f=ZTrw@mail.gmail.com>
Date: Sun, 3 May 2020 10:54:54 +0200
Message-ID: <CAJmjfvXUtWE1r9+PxDnRFkbFXgBG=KpRCcfzAyd3N7P3vYB2=w@mail.gmail.com>
To: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Deprecating uniqid()
From: jakob@givoni.dk (Jakob Givoni)

On Sat, May 2, 2020 at 9:58 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
>
> 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

I'm using this function frequently, but I am ok with deprecating it as
I think the name is dangerously misleading - basically, anything that
mentions "unique" without saying to what, is a misnomer.
However, as it's useful to have a function in core that gives you a
random string with a fixed length that is unique within some
well-defined boundaries, I'd like to be sure there is an easy
replacement for the function when the time comes to upgrade php.
Ideally something that is guaranteed to be unique within the current
php process and takes the same arguments as uniqid.

Best,
Jakob