This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Colm Buckley
Recipients Colm Buckley, Lukasa, alex, christian.heimes, doko, dstufft, larry, lemburg, martin.panter, matejcik, ned.deily, python-dev, rhettinger, skrah, thomas-petazzoni, vstinner, ztane
Date 2016-06-07.18:45:11
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1465325111.83.0.454666522884.issue26839@psf.upfronthosting.co.za>
In-reply-to
Content
Larry -

To the first point:

The combination of Victor's changeset 9de508dc4837 (based on my patch) and my most recent nonblocking_urandom_noraise patch (which is on top of 9de508dc4837) will do what you suggest for the hash secret initialization - ie: it is allowed to fall back to predictable sources when there is insufficient entropy to securely seed it.

I suspect that it is simply impossible to reconcile "os.urandom will never block" with "os.urandom is always cryptographically reasonable". If the system has no entropy, it has no entropy. The only escape I see is to add an exception condition, instead of the silent fallback which some platforms currently have. There is a judgement call to be made here; whether silent fallback is acceptable or not.

As Donald points out, this will fail only in very unusual circumstances (specifically, early in the boot process, although not I think just on the first boot of a system; Debian at least by default does not attempt to preserve its entropy pool across a reboot.)

This should not affect things like web servers etc. as they start much later in the boot process; in particular after networking has started, which I believe is the principal source of entropy for /dev/urandom.

Colm
History
Date User Action Args
2016-06-07 18:45:11Colm Buckleysetrecipients: + Colm Buckley, lemburg, rhettinger, doko, vstinner, larry, christian.heimes, matejcik, ned.deily, alex, skrah, python-dev, martin.panter, ztane, dstufft, Lukasa, thomas-petazzoni
2016-06-07 18:45:11Colm Buckleysetmessageid: <1465325111.83.0.454666522884.issue26839@psf.upfronthosting.co.za>
2016-06-07 18:45:11Colm Buckleylinkissue26839 messages
2016-06-07 18:45:11Colm Buckleycreate