Donald Stufft added the comment: > 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27272> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
