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 Theodore Tso
Recipients Colm Buckley, Lukasa, Theodore Tso, alex, doko, dstufft, larry, lemburg, martin.panter, matejcik, ned.deily, python-dev, rhettinger, skrah, thomas-petazzoni, vstinner, ztane
Date 2016-06-08.14:21:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Oh --- and about people wondering whether os.random is being used for cryptographic purposes or not "most of the time" or not --- again, welcome to my world.  I get complaints all the time from people who try to do "dd if=/dev/urandom of=/dev/hdX bs=4k" and then complain this is too slow.

Creating an os.cryptorandom and os.pseudorandom might be a useful way to go here.  I've often considered whether I should create a /dev/frandom for the crazies who want to use dd as a way to wipe a disk, but to date I've haven't thought it was worth the effort, and I didn't want to encourage them.  Besides, isn't obviously the right answer is to create a quickie python script?  :-)

Splitting os.random does beg the question of what os.random should do, however.  If you go down that path, I'd suggest defaulting to the secure-but-slow choice.

I'd also suggest assuming it's OK to put the onus on the people who are trying to run python scripts during early boot to have to either add some command flags to the python interpreter, or to otherwise make adjustments, as being completely fair.  But again, that's my bias, and if people don't want to deal with trying to ask the systemd folks to make a change in their code, I'd _completely_ understand.

My design preference is that outside of boot scripts, having os.random block in the same of security is completely fair, since in that case you won't deadlock the system.  People of good will may disagree, of course, and I'm not on the Python development team, so take that with whatever grain of salt you wish.   At the end of the day, this is all about tradeoffs, and you know your customer/developer base better than I do.\

Date User Action Args
2016-06-08 14:21:34Theodore Tsosetrecipients: + Theodore Tso, lemburg, rhettinger, doko, vstinner, larry, matejcik, ned.deily, alex, skrah, python-dev, martin.panter, ztane, dstufft, Lukasa, thomas-petazzoni, Colm Buckley
2016-06-08 14:21:34Theodore Tsosetmessageid: <>
2016-06-08 14:21:34Theodore Tsolinkissue26839 messages
2016-06-08 14:21:33Theodore Tsocreate