On Jun 16, 2016, at 12:53 AM, Nathaniel Smith wrote:
We have introduced churn. Predicting a future SO question such as "Can os.urandom() block on Linux?" the answer is "No in Python 3.4 and earlier, yes possibly in Python 3.5.0 and 3.5.1, no in Python 3.5.2 and the rest of the 3.5.x series, and yes possibly in Python 3.6 and beyond".
It also depends on the kernel version, since it will never block on old kernels that are missing getrandom(), but it might block on future kernels if Linux's /dev/urandom ever becomes blocking. (Ted's said that this is not going to happen now, but the only reason it isn't was that he tried to make the change and it broke some distros that are still in use -- so it seems entirely possible that it will happen a few years from now.)
Right; I noticed this and had it in my copious notes for my follow up but forgot to mention it. Thanks!
This is not an accurate docstring, though. The more accurate docstring for your proposed behavior would be:
[...]
You should never use this function. If you need unguessable random bytes, then the 'secrets' module is always a strictly better choice -- unlike this function, it always uses the best available source of cryptographic randomness, even on Linux. Alternatively, if you need random bytes but it doesn't matter whether other people can guess them, then the 'random' module is always a strictly better choice -- it will be faster, as well as providing useful features like deterministic seeding.
Note that I was talking about 3.5.x, where we don't have the secrets module. I'd quibble about the admonition about never using the function. It *can* be useful if the trade-offs are appropriate for your application (e.g. "almost always random enough, but maybe not though at least you won't block and you'll get back something"). Getting the words right is useful, but I agree that we should be strongly recommending crypto applications use the secrets module in Python 3.6.
In practice, your proposal means that ~all existing code that uses os.urandom becomes incorrect and should be switched to either secrets or random. This is *far* more churn for end-users than Nick's proposal.
I disagree. We have a clear upgrade path for end-users. If you're using os.urandom() in pre-3.5 and understand what you're getting (or not getting as the case may be), you will continue to get or not get exactly the same bits in 3.5.x (where x >= 2). No changes to your code are necessary. This is also the case in 3.6 but there you can do much better by porting your code to the new secrets module. Go do that!
...Anyway, since there's clearly going to be at least one PEP about this, maybe we should stop rehashing bits and pieces of the argument in these long threads that most people end up skipping and then rehashing again later?
Sure, I'll try. ;) Cheers, -Barry