Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95942
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <87twdlcs2j.fsf@lil.giraffy.jp>
References: <CAGa2bXYg1kkoYGQNr8T2oTshuqrvweefYO+EdY41w1vwUM32iQ@mail.gmail.com>
 <878tuxenl4.fsf@lil.giraffy.jp> <CAGa2bXaTydTSZniX4dUA9h_FcNaymyqfDXQJO0zx1ZDfLmvWdg@mail.gmail.com>
 <87twdlcs2j.fsf@lil.giraffy.jp>
Date: Mon, 12 Sep 2016 21:08:26 +0900
Message-ID: <CAGa2bXaziNMtNAgsJgX-BCgLL9z2WkoSaP8aNVrAgwo9MJ4WEQ@mail.gmail.com>
To: Kazuo Oishi <kazuo@o-ishi.jp>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Kazuo,

On Mon, Sep 12, 2016 at 7:48 PM, Kazuo Oishi <kazuo@o-ishi.jp> wrote:
>> I know some code breaks, but it's not many. It's not fatal BC also.
>>
>> IMHO, uniqid() should try to generate uniqid() possible. uniqid() does produce
>> non unique ID because it is system time based. This change mitigates impact of
>> misuse also which is common in both open and close codes.
>>
>> Which is important?
>>  - Fix known issues and generate unique ID (as much as possible)
>>  - Let it generate non unique ID and ignore for some code may complain.
>
> IMO, improving it (generate better semi-unique ID) is not important
> enoungh to introduce unnecessary BC break.  (Why returning string length
> is changed?)

It cannot not produce unique ID as name "uniqid()" implies by default.
Reason is described in the RFC. Please read RFC because it's the
official proposal.

Since we have to change "more entropy" to TRUE by default, why not use
much better entropy? php_combined_lcg() is legacy entropy generator
_must not_ be used now. New code's entropy is more than a million
times better for the same length. 50 bits entropy is far less enough for
crypt safety, though.

> If good unique ID generator is needed in core, please create new
> function with another name like "unique_id".

Already is, session_create_id() could be used.
Or UUID if 3rd party module can be used.

Although I would not like to leave legacy functions as much as
possible, this could be a vote option. Any more request for new
function, anyone?

I don't like the name because "unique_id()" implies "absolute unique ID",
but we can only provide "very close to unique ID". I'm not sure if it's good to
have "uniqid()" and "unique_id()" that have the same note:

"This function does not guarantee 100% uniqueness".

If we are going to have unique_id(), I would like to keep timestamp
value, since this improves uniqueness and handy for non crypt usage.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net