Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87876
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain thomasbley.de from 85.13.137.24 cause and error)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: ALL-INKL Webmail 2.11
To: scott@paragonie.com
Cc: internals@lists.php.net, ircmaxell@gmail.com
Message-ID: <20150823132604.1224B26052F@dd15934.kasserver.com>
Date: Sun, 23 Aug 2015 15:26:04 +0200 (CEST)
Subject: Re: [PHP-DEV] [RFC] [Discuss] Random Functions Throwing Exceptions in PHP 7.0.0
From: mails@thomasbley.de ("Thomas Bley")



Scott Arciszewski wrote on 23.08.2015 02:50:

> On Sat, Aug 22, 2015 at 8:33 PM, Thomas Bley <mails@thomasbley.de> wrote:
>> Anthony Ferrara wrote on 22.08.2015 21:58:
>>
>>> All,
>>>
>>> I am putting a simple RFC up for discussion to make random_* throw
>>> exceptions on failure in order to ensure we fail-closed.
>>>
>>> https://wiki.php.net/rfc/random-function-exceptions
>>>
>>> Considering this topic has already been discussed, I intend to open
>>> voting on this as soon as allowable. Given the voting policy specifies
>>> 2 weeks for language changes and 1 week for another, this is assumed
>>> to require 1 week of "discussion".
>>>
>>> With that in mind, I intend to put this RFC up to vote on August 29/30th.
>>>
>>> Thanks!
>>>
>>> Anthony
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>
>> Hi,
>>
>> I think there are a lot of security problems if people ignore return values,
>> e.g. password comparison, user lookup in database, lookups for permissions,
>> etc.
>>
>> Having false + E_WARNING highlighted in the documentation with a yellow box
>> and the Caution title should be enough.
>>
>> For those who want exceptions can implement this in userland:
>> $rand = random_int(10,100);
>> if ($rand === false) {
>>     throw new Exception('error ...');
>> }
>> // or write a wrapper like random_int_exception(...).
>>
>> If people use this function without reading documentation, they will also use
>> other things without documentation like database queries without
>> binding/escaping, inject html without escaping, etc.
>> Having core functions suddenly throw exceptions causes many problems in the
>> code structure.
>>
>> Regards
>> Thomas
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
> 
> Hi Thomas,
> 
> Your proposal effectively blames the user if they get it wrong and
> burdens them with additional responsibilities. Increasing the
> cognitive load of PHP developers will not result in a net gain for the
> security of the applications they develop. I've made this argument
> elsewhere in the course of this discussion.
> 
> Cryptography implementations should do everything reasonable to not
> blame the user, and cryptographic primitives should do everything
> reasonable to not blame the implementor.
> 
> Read this: http://cr.yp.to/talks/2015.01.07/slides-djb-20150107-a4.pdf
> 
>> If people use this function without reading documentation, they will also use
>> other things without documentation like database queries without
>> binding/escaping, inject html without escaping, etc.
>> Having core functions suddenly throw exceptions causes many problems in the
>> code structure.
> 
> Exceptions will only be thrown in exceptional circumstances:
> 
> 1. If they're using shared hosting, and a malicious script triggers a
> file descriptor exhaustion condition on another hosting account (we're
> assuming great sandboxing between customers), an exception will be
> thrown rather than returning FALSE.
> 2. If the system is utterly incapable of generating random numbers.
> 
> An exception must either be handled (try-catch), or it by default
> terminates script execution. This is the best of both worlds:
> 
> 1. It fails closed.
> 2. It's easy to handle gracefully should the developer wish to do so.
> 
> Designing a CSPRNG that will fail closed, without unavoidably killing
> their script (i.e. E_ERROR), will do far more to make PHP applications
> secure than telling people they should RTFM.
> 
> Hackers have been saying RTFM since the ARPANET days, and yet most
> people still don't. It's a losing battle. Let's patch what we can with
> good design decisions.
> 
> TL;DR - the path forward is Throwable. Whether it's an Error object or
> and Exception object (and when it throws which) is what's to be
> discussed and voted on.
> 
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises <https://paragonie.com>
> 

why not have false + e_warning for strict_types=0 and fatal error for strict_types=1 ?
Doing function random_int(): int { ...

Regards
Thomas