Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:102105 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 55572 invoked from network); 11 May 2018 12:46:00 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 May 2018 12:46:00 -0000 Authentication-Results: pb1.pair.com smtp.mail=alice@librelamp.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=alice@librelamp.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain librelamp.com designates 45.79.96.192 as permitted sender) X-PHP-List-Original-Sender: alice@librelamp.com X-Host-Fingerprint: 45.79.96.192 librelamp.com Received: from [45.79.96.192] ([45.79.96.192:36626] helo=librelamp.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 8E/5D-47313-58095FA5 for ; Fri, 11 May 2018 08:45:58 -0400 Received: from localhost.localdomain (92.sub-174-215-7.myvzw.com [174.215.7.92]) by librelamp.com (Postfix) with ESMTPSA id 3DF202675 for ; Fri, 11 May 2018 12:45:54 +0000 (UTC) To: internals@lists.php.net References: Message-ID: Date: Fri, 11 May 2018 05:45:53 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Deprecation of uniqid() From: alice@librelamp.com (Alice Wonder) On 05/11/2018 05:34 AM, Alice Wonder wrote: > On 05/11/2018 05:10 AM, Alice Wonder wrote: >> On 05/11/2018 03:50 AM, Arvids Godjuks wrote: >>> 2018-05-11 12:36 GMT+02:00 Alice Wonder : >>> >>>> On 05/11/2018 01:59 AM, Arvids Godjuks wrote: >>>> >>>>> 2018-05-10 16:33 GMT+02:00 Niklas Keller : >>>>> >>>>> Hey, >>>>>> >>>>>> I hereby propose to deprecate uniqid(). There have been attempts to >>>>>> fix >>>>>> it >>>>>> ( >>>>>> https://wiki.php.net/rfc/uniqid), but those were rejected during >>>>>> discussion, because there's no possible fix without breaking BC. >>>>>> Instead >>>>>> of >>>>>> a subtle BC break, this RFC favors the deprecation and moving >>>>>> users to >>>>>> other functions. >>>>>> >>>>>> It's to be discussed whether the function should be removed with >>>>>> PHP 8.0 >>>>>> or >>>>>> just deprecated to avoid fully breaking things where it's not >>>>>> strictly >>>>>> necessary. A deprecation will probably avoid most new usages, >>>>>> which is >>>>>> the >>>>>> main goal. >>>>>> >>>>>> RFC: https://wiki.php.net/rfc/deprecate-uniqid >>>>>> >>>>>> Kind Regards, >>>>>> Niklas >>>>>> >>>>>> -- >>>>>> PHP Internals - PHP Runtime Development Mailing List >>>>>> To unsubscribe, visit: http://www.php.net/unsub.php >>>>>> >>>>>> >>>>>> Hello, >>>>> >>>>> as a userland user of this function I do disagree with it's outright >>>>> removal. It has it's uses. >>>>> What can be done with it is drop the $more_entropy flag and make it >>>>> generate at least as long strings and use random_bytes under the >>>>> hood for >>>>> a >>>>> better random. >>>>> It can also adopt a length parameter so you can vary the random >>>>> part as >>>>> much as you need it. >>>>> >>>>> You don't always need a truly random token - I have a system that uses >>>>> uniqid to generate tens of thousands tokens per request and it's >>>>> actually >>>>> a >>>>> good thing they are time based at the start of it with a random >>>>> part at >>>>> the >>>>> end (as I said the random part should be improved and get rid of that >>>>> stupid dot when generating with $more_entropy = true). >>>>> >>>>> >>>> It seems to me that for your use case, you could just use the time() >>>> function to get part of your unique id and then use libsodium to >>>> generated >>>> a nonce for the "random" part, using sodium's function for increment >>>> the >>>> nonce between each use. >>>> >>>> Predictable, sure, but your use case says they don't need to be a truly >>>> random token - just unique (essentially a non-random nonce) but with >>>> a time >>>> component. >>>> >>>> >>>> -- >>>> PHP Internals - PHP Runtime Development Mailing List >>>> To unsubscribe, visit: http://www.php.net/unsub.php >>>> >>>> >>> Hello Alice, >>> >>> Sure, there is lots I can do about that project, including what you have >>> described. One thing though - client does not need it or want it or >>> want's >>> to pay for that work. That whole project is a poster child for a "side >>> project on a bare minimum, but done by a competent developer instead >>> of a >>> student so it actually works in the long run" >>> >> >> Tell the client they can use this for free. >> >> function compat_uniqid(string $prefix='', bool $more_entropy = false) >> { >> static $nonce = null; >> if(is_null($nonce)) { >> $nonce = random_bytes(SODIUM_CRYPTO_SECRETBOX_NONCEBYTES); >> } >> $m = microtime(true); >> $return = sprintf("%8x%05x",floor($m),($m-floor($m))*1000000); >> if($more_entropy) { >> sodium_increment($nonce); >> $x = hexdec(substr(bin2hex($nonce),0,8)); >> $x = str_pad($x, 12, "0", STR_PAD_LEFT); >> $return = $return . substr($x, 0, 1) . '.' . substr($x, -8); >> } >> return $prefix . $return; >> } >> > > slightly better if block > > if($more_entropy) { > sodium_increment($nonce); > $x = hexdec(substr(bin2hex($nonce),0,12)); > $return = $return . substr($x, 2, 1) . '.' . substr($x, -8); > } > > Obvious patterns in the "more entropy" but the output in only suppose to > be unique, not random. > My point is that since it is trivial to create a function that is compatible with the php function for backwards compatibility, the problematic function in php itself doesn't need to exist. For an actual unique id, code should be updated to generate an actual nonce (either with pRNG every call or first time and increment if predictable is okay) rather than use a function that clearly fails to always produce something unique. So the function should go. If I had a vote I would vote for the RFC and deprecate it.