On 23 June 2016 at 11:13, Donald Stufft <don...@stufft.io> wrote:
>
>> On Jun 23, 2016, at 2:10 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
>>
>> That second one has the added bonus of doing the right thing even on
>> older Linux kernels that don't provide the new getrandom() syscall,
>> creating the following virtuous feedback loop:
>
>
> The second one also is not a good idea to use in the general case since it
> will also block randomly throughout the application. It’s OK to use if you
> know you’re only going to access it once on boot, but you wouldn’t want it to
> be a common idiom that software itself does. If I recall, there was major
> downtime on healthcare.gov because they used /dev/random in production.
Right, the idiom I'd be recommending in PEP 522 is a "Do this once in
__main__ to categorically prevent BlockingIOError from os.urandom,
random.SystemRandom and the secrets module" application level
approach, while the guidance for libraries would be to just keep using
os.urandom() and let affected application developers worry about
whether to catch the BlockingIOError at point of use, or block the
application at startup to wait for the system RNG.
Although now I'm wondering whether it might be worth proposing a
"secrets.wait_for_system_rng()" API as part of PEP 522, with the
following implementation:
def wait_for_system_rng():
# Avoid the below busy loop if possible
try:
block_on_system_rng = open("/dev/random", "rb")
except FileNotFoundError:
pass
else:
with block_on_system_rng:
block_on_system_rng.read(1)
# Busy loop until the system RNG is ready
while True:
try:
os.urandom(1)
break
except BlockingIOError:
pass
Since this is an "at most once at application startup" kind of
problem, I like the way that having a separate function for waiting
helps to divide responsibilities between library API developers
("complain if you need the system RNG and it isn't ready") and
application developers ("ensure the system RNG is ready before calling
APIs that need it").
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Security-SIG mailing list
Security-SIG@python.org
https://mail.python.org/mailman/listinfo/security-sig
