http://bugs.python.org/issue27288 covers updating the secrets module to use getrandom().
http://bugs.python.org/issue27292 covers documenting the drawbacks of os.urandom() http://bugs.python.org/issue27293 covers documenting all of the issues pointed out in this discussion. Only issue I can think of that we're missing is one to track reverting os.urandom() to 3.4 semantics (any doc updates required for the random module?). Am I missing anything? On Sat, Jun 11, 2016, 12:41 Guido van Rossum <gu...@python.org> wrote: > On Sat, Jun 11, 2016 at 11:30 AM, Donald Stufft <don...@stufft.io> wrote: > >> >> On Jun 11, 2016, at 1:39 PM, Guido van Rossum <gu...@python.org> wrote: >> >> Is the feature detection desire about being able to write code that runs >> on older Python versions or for platforms that just don't have getrandom()? >> >> My assumption was that nobody would actually use these flags except the >> secrets module and people writing code that generates long-lived secrets -- >> and the latter category should be checking platform and versions anyway >> since they need the whole stack to be secure (if I understand Ted Ts'o's >> email right). >> >> My assumption is also that the flags should be hints (perhaps only >> relevant on Linux) -- platforms that can't perform the action desired >> (because their system's API doesn't support it) would just do their default >> action, assuming the system API does the best it can. >> >> >> The problem is that someone writing software that does >> os.urandom(block=True) or os.urandom(exception=True) which gets some bytes >> doesn’t know if it got back cryptographically secure random because Python >> called getrandom() or if it got back cryptographically secure random >> because it called /dev/urandom and that gave it secure random because it’s >> on a platform that defines that as always returning secure or because it’s >> on Linux and the urandom pool is initialized or if it got back some random >> bytes that are not cryptographically secure because it fell back to reading >> /dev/urandom on Linux prior to the pool being initialized. >> >> The “silently does the wrong thing, even though I explicitly asked for it >> do something different” is something that I would consider to be a footgun >> and footgun’s in security sensitive code make me really worried. >> > > Yeah, but we've already established that there's a lot more upset, > rhetoric and worry than warranted by the situation. > > >> Outside of the security side of things, if someone goes “Ok I need some >> random bytes and I need to make sure it doesn’t block”, then doing >> ``os.random(block=False, exception=False)`` isn’t going to make sure that >> it doesn’t block except on Linux. >> > > To people who "just want some random bytes" we should recommend the random > module. > > >> In other words, it’s basically impossible to ensure you get the behavior >> you want with these flags which I feel like will make everyone unhappy >> (both the people who want to ensure non-blocking, and the people who want >> to ensure cryptographically secure). These flags are an attractive nuisance >> that look like they do the right thing, but silently don’t. >> > > OK, it looks like the flags just won't make you happy, and I'm happy to > give up on them. By default the status quo will win, and that means neither > these flags nor os.getrandom(). (But of course you can roll your own using > ctypes. :-) > > >> Meanwhile if we have os.urandom that reads from /dev/urandom and >> os.getrandom() which reads from blocking random, then we make it both >> easier to ensure you get the behavior you want, either by using the >> function that best suits your needs: >> >> * If you just want the best the OS has to offer, os.getrandom falling >> back to os.urandom. >> > > Actually the proposal for that was the secrets module. And the secrets > module would be the only user of os.urandom(blocking=True). > > >> * If you want to ensure you get cryptographically secure bytes, >> os.getrandom, falling back to os.urandom on non Linux platforms and >> erroring on Linux. >> > > "Erroring" doesn't sound like it satisfies the "ensure" part of the > requirement. And I don't see the advantage of os.getrandom() over the > secrets module. (Either way you have to fall back on os.urandom() to > suppport Python 3.5 and before.) > > >> * If you want to *ensure* that there’s no blocking, then os.urandom on >> Linux (or os.urandom wrapped with timeout code anywhere else, as that’s the >> only way to ensure not blocking cross platform). >> > > That's fine with me. > > >> * If you just don’t care, YOLO it up with either os.urandom or >> os.getrandom or random.random. >> > > Now you're just taking the mickey. > > >> >> I think the problem with making os.urandom() go back to always reading >> /dev/urandom is that we've come to rely on it on all platforms, so we've >> passed that station. >> >> >> Sorry, to be more specific I meant the 3.4 behavior, which was >> open(“/dev/urandom”).read() on *nix and CryptGenRandom on Windows. >> > > I am all for keeping it that way. The secrets module doesn't have to use > any of these, it can use an undocumented extension module for all I care. > Or it can use os.urandom() and trust Ted Ts'o. > > -- > --Guido van Rossum (python.org/~guido) > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/brett%40python.org >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
