[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 03:49:43 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 Fri, Jun 10, 2016 at 01:06:45PM -0700, Larry Hastings wrote:
On 06/10/2016 01:01 PM, David Mertz wrote: >So yes, I think 3.5.2 should restore the 2.6-3.4 behavior of os.urandom(), That makes... five of us I think ;-) (Larry Guido Barry Tim David)
>and the NEW APIs in secrets should use the "best available randomness >(even if it blocks)" I'm not particular about how the new API is spelled. However, I do think os.getrandom() should be exposed as a thin wrapper over getrandom() in 3.6. That would permit Python programmers to take maximal advantage of the features offered by their platform. It would also permit the secrets module to continue to be written in pure Python.
A big +1 for that.
Will there be platforms where os.getrandom doesn't exist? If not, then secrets can just rely on it, otherwise what should it do?
if hasattr(os, 'getrandom'): return os.getrandom(n) else: # Fail? Fall back on os.urandom?
-- 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 ]