On 07.06.2016 16:59, Christian Heimes wrote:
> 
> Christian Heimes added the comment:
> 
> On 2016-06-07 16:49, Marc-Andre Lemburg wrote:
>> This gives people a clear choice and doesn't cause people
>> to have to reconsider using the random module or wait for
>> Python hash randomization to initialize itself when using
>> Python during VM/container/system startup.
>>
>> I don't really appreciate this approach to break Python in
>> cloud setups just because some entropy pool is not initialized,
>> which only a tiny fraction of users care about. It doesn't
>> make Python land a better place.
> 
> VM and cloud setup without a proper CPRNG source are plain broken. True
> fact!
> 
> Secure entropy sources are a fundamental resource for all modern
> applications. Please start treating CPRNG like RAM, CPU or disks. You
> wouldn't add a workaround for broken CPU instructions to math.c or
> semi-functional network card to socket.c, would you?

For security relevant applications, I agree and for those
I question the use of os.urandom() altogether (see my other
replies), but for everything else, a PRNG is just fine.

I'm repeating myself, but making users believe that an
entropy source is more important that preventing a
denial of service just won't work out.

You're position is quite similar to the one that others
have taken with the I/O encoding in Python3. Their stance
was "fix your system and it'll work". Well, tell that
to 9-year olds who want to learn Python.

Likewise, it may be easy for you to track down the reason
why Python 3.5.1 isn't working in your VM or container,
but not everyone knows that there's an entropy source
which needs to be connected to your VM or container to
make things work - and even if they do know about the problem
they may not have the means to do so.

It's pretty much the same situation and the reason why
we have "practicality beats purity".

A hanging Python process is the worst of all user
experiences.