[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits? (original) (raw)
Steven D'Aprano steve at pearwood.info
Sat Jun 11 23:15:17 EDT 2016
- Previous message (by thread): [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
- Next message (by thread): [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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:
https://wiki.python.org/moin/EmbeddedPython
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 script:
- 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.
-- Steve
- Previous message (by thread): [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
- Next message (by thread): [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]