[Security-sig] RFC: PEP: Make os.urandom() blocking on Linux

[Nick Coghlan]

On 24 June 2016 at 06:48, Barry Warsaw <barry at python.org> wrote:
>
> If secrets is backported and available in PyPI, then we can start immediately
> changing the os.urandom() meme to something more secure.  Sure it takes a long
> time to change minds, but I still think it's better to give users a blessed,
> near universally agreed upon, secure alternative immediately.

It's not that simple, as secrets relies on the os module to provide
access to the getrandom() syscall (by way of an upgraded os.urandom).
Nothing changes from a security perspective without that additional
level of access to the underlying operating system capabilities. You
could potentially go the ctypes route in a PyPI module, but the
performance would be abysmal, so nobody would use it.

Going for a custom C extension doesn't really work either - you can't
use manylinux1 for it (as the baseline glibc ABI is way too old to
include getrandom), and nobody's going to want to introduce an install
time compiler dependency just to address this relatively obscure
concern.

Even if those problems could be resolved, it isn't really a problem
where I'd advocate for a "standard library only" project to add an
external dependency to address it - if they're going to do that, I'd
instead advocate for them to stop reinventing the wheel, and instead
reach for a third party library that solves their *actual* problem
(like cryptography, passlib, or one of the web frameworks).

This is why I think it makes sense to focus the immediate discussion
on "Given getrandom() as an operating system API, can we improve the
semantics of Python's os.urandom()?". The wider discussion around "How
do we educate Python developers on the difference between simulated
uncertainty and sensitive secrets?" that motivated the introduction of
the secrets module isn't really applicable.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia