Hi Kauzo,

On Tue, Sep 13, 2016 at 3:23 PM, Kazuo Oishi <ka...@o-ishi.jp> wrote:
>> Current implementation is good enough for most cases, but it can be better.
>
> I agree this legacy design API works good enough for most cases.
>
> So, I think it should not be changed in BC break way.

I updated the RFC.
2nd parameter (more_entropy) is int now.

 - 0 for disable more entropy.
   (Compatible with current $more_entropy=FALSE)
 - 1 for 10 digits entropy. e.g. 1.23456789
   (Compatible with current $more_entropy=TRUE) DEFAULT
 - 13 to 255 to number of entropy [0-v]{13,255} chars.
   e.g. 1234abcdefghi (13 = 65 bits)
   65 bits entropy + timestamp will provide good enough uniqueness for
most usage.

More secure default may be future scope, but attack against misused
code will be much harder by default as a bonus.

Default could be more secure by using [0-v]+.
Marco does not like "." in default output.

I would like to choose default from discussion (or make some vote choices)

Current behavior is not an option because whole point of this RFC is
to make uniqid() to return unique ID almost always even when system
clock is adjusted.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to