2016-06-23 2:35 GMT+02:00 Barry Warsaw <ba...@python.org>: > Because the os module has traditionally surfaced lower-level operating system > functions,
Well, that's not true. os.urandom() is a bad example since it has many implementations depending on the platform. https://haypo-notes.readthedocs.io/pep_random.html#leave-os-urandom-unchanged-add-os-getrandom or https://haypo-notes.readthedocs.io/pep_random.html#operating-system-random-functions > That's also why I > advocate simplifying os.urandom() so that it reverts more or less to exposing > /dev/urandom to Python. With perhaps a few exceptions, os doesn't provide > higher level APIs. Hum, I modified os.urandom() to use getrandom() to use the private file descriptor and not require the /dev/urandom device. Using a file descriptor has many issues. Tell me if you need more details on these issues. In Python 3.5.2, os.urandom() uses getrandom() on Linux, but only falls back on reading /dev/urandom is getrandom(GRND_NONBLOCK) fails with EAGAIN. I'm not sure that I understand you. Do you want to stop using getrandom()? What about getrandom() on Solaris? And getentropy() on OpenBSD? (And Windows uses CryptGenRandom() ;-)) > The point here is that, let's say you're an experienced Linux developer and > you know you want to use getrandom(2) in Python. os.getrandom() is exactly > that. It's completely analogous to why we provide, e.g. os.chroot() and such. Even if we modify os.urandom() to make it blocking, adding os.getrandom() makes sense. getrandom() allows also to read /dev/random (not /dev/urandom) without using a FD, getrandom(GRND_NONBLOCK) also gives access to the non-blocking mode. Victor _______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig
