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 Lukasa
Recipients Lukasa, alex, dstufft, vstinner
Date 2016-06-07.12:32:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1465302764.98.0.117220610893.issue27250@psf.upfronthosting.co.za>
In-reply-to
Content
Let me make the security person argument even though you've dismissed it in your original post:

Security should be on by default and opted out of, not the other way around. If the obvious choice is insecure then users who aren't careful enough won't notice, because even bad RNGs produce numbers that *look* random if not carefully evaluated. This means they won't fix it and it will stay there, broken, until they are attacked (which they may never notice).

On the other hand, if the obvious choice is secure then users who aren't careful enough (that is, ones that don't care about security but do care about blocking) *will* notice, because their apps will hang on startup. They'll investigate the hang, see the docs, and fix their code. This is a *much better* failure mode. There is a reason that modern cars warn you about any upcoming problem with the car (e.g. worn brake pads, low oil etc.): users whose expectations are violated in a way they can easily detect are much more likely to act than users whose expectations are subtly violated.

This is doubly true here, because the only system that is complaining about the random numbers right now is CPython, which, being the same system providing these new functions, can always ensure that it's doing the right thing. With this patch as proposed here, external library developers need to see this discussion and realise that, for Python 3.5 or lower, they want os.urandom, and for Python 3.6 and higher, they want os.urandom_block(). And, again, because os.urandom() still appears to produce high quality random numbers (and most of the time *actually does so*), I guarantee at least one application will not notice the change and will become open to attack.

Those are the two arguments for making non-blocking be explicit, rather than making blocking be specific.
History
Date User Action Args
2016-06-07 12:32:45Lukasasetrecipients: + Lukasa, vstinner, alex, dstufft
2016-06-07 12:32:44Lukasasetmessageid: <1465302764.98.0.117220610893.issue27250@psf.upfronthosting.co.za>
2016-06-07 12:32:44Lukasalinkissue27250 messages
2016-06-07 12:32:44Lukasacreate