Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107301 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 23534 invoked from network); 23 Sep 2019 18:56:02 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 23 Sep 2019 18:56:02 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id 9B6042D1FD3 for ; Mon, 23 Sep 2019 09:34:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp3.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15623 62.12.128.0/17 X-Spam-Virus: No Received: from mail.gna.ch (darkcity.gna.ch [62.12.172.119]) by php-smtp3.php.net (Postfix) with ESMTP for ; Mon, 23 Sep 2019 09:34:40 -0700 (PDT) Received: from [10.0.1.55] (77-56-180-37.dclient.hispeed.ch [77.56.180.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by darkcity.gna.ch (Postfix) with ESMTPSA id 2697A21E27; Mon, 23 Sep 2019 18:34:38 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) In-Reply-To: <696dc114-c2df-40aa-aad6-5b87d4373c0e@www.fastmail.com> Date: Mon, 23 Sep 2019 18:34:37 +0200 Cc: php internals Content-Transfer-Encoding: quoted-printable Message-ID: <9479751B-281E-4590-85E7-51EEAF066C73@cschneid.com> References: <696dc114-c2df-40aa-aad6-5b87d4373c0e@www.fastmail.com> To: Larry Garfield X-Mailer: Apple Mail (2.3445.104.11) X-Envelope-From: Subject: Re: [PHP-DEV] PHP 7.4 BC break with openssl_random_pseudo_bytes() From: cschneid@cschneid.com (Christian Schneider) Am 23.09.2019 um 17:16 schrieb Larry Garfield : > I cannot speak for OpenSSL, but random_bytes() and random_int() were = changed very late in the 7.0 cycle to throw exceptions so that they = "fail closed". Otherwise if you expect a random value back but get a = constant value (false or empty string), if you don't remember to check = it yourself every time then you now have a security hole because you're = using a constant seed for random-dependent behavior. I see your point but I'm still not convinced that it is worth the BC. But whatever is decided for this specific change, I'm more interested in = handling this properly for future RFCs, i.e. people should get the full = picture concerning BC before voting. A little side-node: random_int(0, 0) does not throw an exception which = makes random_bytes and random_int inconsistent by your logic ;-) - Chris