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 dstufft
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.14:09:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1465308550.21.0.164752726669.issue26839@psf.upfronthosting.co.za>
In-reply-to
Content
> I have no objection to *deliberate* invocations of the system RNG blocking if needed. Presumably this behavior can be codified into the various APIs.
>
> My objection is *entirely* to _PyRandom_Init() calling a potentially-blocking RNG source, before script parsing even begins.

It sounds like we might (somehwat?) be in violent agreement then.

If someone calls os.urandom() (or calls something that causes it to be called, e.g. secrets.py, random.SystemRandom, etc) then they should not get randomness from an un-initialized /dev/urandom by default. I have a preference for blocking until randomness is available, but an exception would be OK too.

I have no problem with the interpreter start up not blocking on entropy because no user invoked code caused that, and the security properties of SipHash that need really good random only really matter for long lived processes that processes a lot of user input-- IOW stuff that's unlikely to be started prior to the pool being initialized.
History
Date User Action Args
2016-06-07 14:09:10dstufftsetrecipients: + dstufft, lemburg, rhettinger, doko, vstinner, larry, christian.heimes, matejcik, ned.deily, alex, skrah, python-dev, martin.panter, ztane, Lukasa, thomas-petazzoni, Colm Buckley
2016-06-07 14:09:10dstufftsetmessageid: <1465308550.21.0.164752726669.issue26839@psf.upfronthosting.co.za>
2016-06-07 14:09:10dstufftlinkissue26839 messages
2016-06-07 14:09:09dstufftcreate