[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
steve at pearwood.info
Sat Jun 11 23:15:17 EDT 2016
On Sat, Jun 11, 2016 at 02:16:21PM -0700, Guido van Rossum wrote:
[on the real-world consequences of degraded randomness from /dev/urandom]
> Actually it's not clear to me at all that it could have happened to Python.
> (Wasn't it an embedded system?)
A Raspberry Pi. But don't people run Python on at least some embedded
systems? The wiki thinks so:
And I thought that was the purpose of µPython.
> > Actually the proposal for that was the secrets module. And the secrets
> > module would be the only user of os.urandom(blocking=True).
> > I’m fine if this lives in the secrets module— Steven asked for it to be an
> > os function so that secrets.py could continue to be pure python.
> The main thing that I want to avoid is that people start cargo-culting
> whatever the secrets module uses rather than just using the secrets module.
> Having it redundantly available as os.getrandom() is just begging for
> people to show off how much they know about writing secure code.
That makes sense.
I'm happy for getrandom to be an implementation detail of secrets, but
I'll need help with that part.
> >> * 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.
> But what is a Python script going to do with that error? IIUC this kind of
> error would only happen very early during boot time, and rarely, so the
> most likely outcome is a hard-to-debug mystery failure.
In my day job, I work for a Linux sys admin consulting company, and I
can tell you from our experience that debugging a process that
occasionally hangs mysteriously during boot is much harder than
debugging a process that occasionally fails with an explicit error in
the logs, especially if the error message is explicit about the cause:
OSError: entropy pool has not been initialized yet
At that point, you can take whatever action is appropriate for your
- fail altogether, just as it might fail if it requires a writable
file system and can't find one;
- sleep for three seconds and try again;
- log the error and proceed with degraded randomness or functionality;
- change it so the script runs later in the boot process.
More information about the Python-Dev