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 christian.heimes, dstufft, martin.panter, tim.peters, vstinner
Date 2016-06-09.17:08:56
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> But that's not what real-life programs expose.

Are you sure? Searching github pulls up a number of results of people calling it, but I haven't looked through them to see how/why they're calling it.

> What do you believe?  For example, do you believe it would remain a disaster if MT initialization wanted only 1 byte from urandom()?  Or is 0 the only value you can live with?

I don't really care that much what random.Random initialized with except as it related to what os.urandom does by default. Here's a copy/paste from my email to python-dev about it:

* Use getrandom(GRND_NONBLOCK) for random.Random since it doesn't matter if we
  get cryptographically secure random numbers or not.
* Switch it to use something other than a CSPRNG by default since it doesn't
  need that.
* Instead of seeding itself from os.urandom on import, have it lazily do that
  the first time one of the random.rand* functions are called.
* Do nothing, and say that ``import random`` relies on having the kernel's
  urandom pool initialized.

Between these options, I have a slight preference for switching it to use a non CSPRNG, but I really don't care that much which of these options we pick. Using random.Random is not secure and none of the above options meaningfully change the security posture of something that accidently uses it.
Date User Action Args
2016-06-09 17:08:56dstufftsetrecipients: + dstufft, tim.peters, vstinner, christian.heimes, martin.panter
2016-06-09 17:08:56dstufftsetmessageid: <>
2016-06-09 17:08:56dstufftlinkissue27272 messages
2016-06-09 17:08:56dstufftcreate