Cory Benfield added the comment:

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.

----------
nosy: +Lukasa

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27250>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to