On 6/9/2016 9:48 AM, Doug Hellmann wrote: > >> On Jun 9, 2016, at 9:27 AM, Cory Benfield <cory at lukasa.co.uk> >> wrote: >> The problem here is that both definitions of ‘broken’ are unclear. >> If we leave os.urandom() as it is, there is a small-but-nonzero >> change that your program will hang, potentially indefinitely. If we >> change it back, there is a small-but-nonzero chance your program >> will generate you bad random numbers. >> >> If we assume, for a moment, that os.urandom() doesn’t get called >> during Python startup (that is that we adopt Christian’s approach >> to deal with random and SipHash as separate concerns), what we’ve >> boiled down to is: your application called os.urandom() so early >> that you’ve got weak random numbers, does it hang or proceed? Those >> are literally our two options. > > I agree those are the two options. I want the application developer > to make the choice, not us. I think the 'new API' should be a parameter, not a new function. With just two choices, 'wait' = True/False could work. If 'raise an exception' were added, then 'action (when good bits are not immediately available' = 'return (best possible)' or 'wait (until have good bits)' or 'raise (CryptBitsNotAvailable)' In either case, there would then be the question of whether the default should match 3.5.0/1 or 3.4 and before. -- Terry Jan Reedy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4