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 christian.heimes
Recipients Colm Buckley, Lukasa, Theodore Tso, alex, christian.heimes, doko, dstufft, larry, lemburg, martin.panter, matejcik, ned.deily, python-dev, rhettinger, skrah, thomas-petazzoni, vstinner, ztane
Date 2016-06-08.08:43:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1465375380.54.0.788536452448.issue26839@psf.upfronthosting.co.za>
In-reply-to
Content
Cory, thanks for summing it up for us. I totally agree with you. In my opinion it is troublesome to have different behavior on platforms. We can implement a workaround for Linux, but not for BSD. Or would O_NONBLOCK cause read() to fail with EWOULDBLOCK on /dev/urandom device?

It might be secure enough to use srandom() / random() instead of /dev/urandom in some platforms. It still won't do any good on platforms like Raspberry Pie since the SoC has no RTC. Without a RTC the clock is not set yet. It happens much later in the boot phase when network is available.

I don't see a cross-platform solution that is able to handle this super-special case without opening a potential security issue for the majority of users.
History
Date User Action Args
2016-06-08 08:43:00christian.heimessetrecipients: + christian.heimes, lemburg, rhettinger, doko, vstinner, larry, matejcik, ned.deily, alex, skrah, python-dev, martin.panter, ztane, dstufft, Lukasa, thomas-petazzoni, Colm Buckley, Theodore Tso
2016-06-08 08:43:00christian.heimessetmessageid: <1465375380.54.0.788536452448.issue26839@psf.upfronthosting.co.za>
2016-06-08 08:43:00christian.heimeslinkissue26839 messages
2016-06-08 08:43:00christian.heimescreate