On 8 August 2016 at 14:22, Nick Coghlan <ncogh...@gmail.com> wrote: > On 8 August 2016 at 13:32, Nick Coghlan <ncogh...@gmail.com> wrote: > >> The Fedora Rawhide experiment I'm proposing in that email to the Fedora >> Python list should give us the data we (Fedora) need to decide whether or >> not this is one of those cases where it makes sense for us to carry a patch >> - if we get zero hits from the exception in ABRT, then it means the default >> blocking behaviour should be relatively safe (since people won't be >> encountering it), so we can drop the patch before the F26 Beta release, and >> Guido will have a solid data point backing up his design instincts. If we >> *do* get hits on the exception, then exactly what we do will depend on the >> nature of those hits, and in particular whether or not the change is >> helping folks find misconfigured Fedora environments they hadn't previously >> noticed, or if they're spurious notifications in situations where just >> blocking for a few hundred milliseconds would have resolved the problem on >> its own (as tested by inserting a "python -c 'import os; os.getrandom(1)" >> before whatever application startup is triggering the new exception). >> > > I started thinking a bit more about the outcomes we'd be looking for from > such an experiment [1], and that reminded of the fact we could potentially > do that with a much lower level of divergence if the upstream > implementation issued a runtime warning when it needed to fall back to > blocking behaviour. That is, rather that just calling "getrandom(size, 0)" > unconditionally, the current logic for trying "getrandom(size, > GRND_NONBLOCK)" first could be kept, and only the fallback to reading from > "/dev/random/" changed to instead call "getrandom(size, 0)" with a > preceding call to PyErr_Warn. >
Sorry, unhelpful typo there: the fallback is to "/dev/urandom", I just mistyped it and missed the error on proofreading. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig
