On 30 July 2016 at 02:52, Victor Stinner <[email protected]> wrote: > 2016-07-29 17:37 GMT+02:00 Nick Coghlan <[email protected]>: >>> Ok, but imagine that you use the "expensive" GRNG_RANDOM (/dev/random >>> rather than /dev/urandom). A first call returns 4000 bytes of "high >>> quality" random bytes, but user requested 4096 bytes and the second >>> call fails. >> >> I'd say in the non-EINTR case with GRNG_RANDOM it would be reasonable >> to return a short read. So folks using that flag would need a >> Python-level loop, but folks using the kernel's CSPRNG wouldn't. > > Do you mean return the 4000 bytes and *ignores* the error?
I'm not clear on the ways that GRNG_RANDOM can fail (other than EINTR), so I'm not sure. I just think we have a fair bit of leeway for the behaviour of that flag to be less user friendly than the default behaviour, since the "may block unexpectedly during normal execution" behaviour is already inherently user unfriendly :) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia _______________________________________________ Security-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/security-sig
