This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients Colm Buckley, Lukasa, alex, christian.heimes, doko, dstufft, larry, lemburg, martin.panter, matejcik, ned.deily, python-dev, rhettinger, skrah, thomas-petazzoni, vstinner, ztane
Date 2016-06-07.20:01:29
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
On 07.06.2016 21:12, Cory Benfield wrote:
>> Python hash randomization only happens once.  So it's not a matter of how early we try the attack, it's a matter of how early we seed Python hash randomization.
> Sorry Larry, I was insufficiently clear (relying on context from earlier). I totally agree that Python startup should not block. I'm saying that having getrandom() called in "blocking mode" for os.urandom, random.SystemRandom, and secrets is not a DoS vector.

I'm not sure I follow. A delay of 90 seconds on startup of a VM
or container can easily lead the supervisor style management tool
to think that something is wrong and issue a retry. Depending on
the configuration it'll then try this a couple of times and
give up.

Overall, I have a hard time following the arguments.

To be clear: getrandom() on Linux is just a wrapper with some
additional control around /dev/random and /dev/urandom.

Unlike /dev/urandom, getrandom() without flag GRND_NONBLOCK will
block, but only in the case where the entropy pool has not been
initialized yet. Once this has been done, it will never block
again, and happily send you poor random data if the entropy pool
has been completely wiped of any entropy data - without telling

So now, you're all arguing: oh my, it's so insecure to use
data from /dev/urandom when the entropy pool is not initialized.
But you're not worried about os.urandom() happily sending you data
which is no longer based on any external entropy half an hour later:

This doesn't make sense. Either you're worried all the time,
or you're not :-)

The whole discussion is centering around whether to block
on an uninitialized entropy pool or not. This can only happen
during startup. By falling back to reading /dev/urandom
in case of an uninitialized pool, you are reading data from
a not fully initialized pool, but you still get random data.
That's really all that's needed for basic operations like
hash seeding or seeding the PRNG in the random module.
And it's limited to Python processes which are run very
early in the VM/container startup phase.

Note that "uninitialized" only means that the kernel entropy
pool has not yet reached an "entropy level" of 128 (whatever
that means):

It does not mean that you're just reading a list of zeros.

So given all this information, why is it that you get so
tangled up in wanting os.urandom() to block during system
startup ?

Or put differently: Where is the attack vector that blocking
behavior of os.urandom() would help remedy ?
Date User Action Args
2016-06-07 20:01:30lemburgsetrecipients: + lemburg, rhettinger, doko, vstinner, larry, christian.heimes, matejcik, ned.deily, alex, skrah, python-dev, martin.panter, ztane, dstufft, Lukasa, thomas-petazzoni, Colm Buckley
2016-06-07 20:01:29lemburglinkissue26839 messages
2016-06-07 20:01:29lemburgcreate