On 8 August 2016 at 20:04, Petr Viktorin <pvikt...@redhat.com> wrote:
> On 08/08/2016 06:09 AM, Nick Coghlan wrote: > >> Elaborating a bit further on the nature of the proposed Rawhide >> experiment, the cases we're trying to distinguish are: >> >> - it doesn't really matter, because it doesn't happen much (few or no >> ABRT hits) >> - it happens, but blocking briefly resolves it (a preceding "python -c >> 'import os; os.getrandom(1)" eliminates the exception) >> - it happens, and blocking causes an indefinite hang (a preceding >> "python -c 'import os; os.getrandom(1)" never completes) >> >> If the feedback from Rawhide builds with the patch applied all falls >> into the first two categories, then we should drop the patch before F26 >> Beta and stick with the upstream behaviour of a cross-platform blocking >> os.urandom() implementation, with folks that want to opt-in to >> non-blocking behaviour pointed to the new os.getrandom() API. >> >> It's only if we get a significant number of bug reports that fall into >> the third category that we'd consider keeping the patch, as those are >> the ones where blocking implicitly won't help, and in fact may make a >> system level configuration problem harder to diagnose. >> >> Cheers, >> Nick. >> > > Hi, > I agree with doing this experiment. > > Two notes that should appear in the Change page: > > This modification should only affect code that runs early in system boot. > It is quite a special case, and Fedora is in a special position with some > fairly low-level parts of system written in Python. > > The raised BlockingIOError should advertise that it is Fedora-specific > behavior, e.g. with a link to the Change page. > Writing my posts here reminded me of an idea that came up earlier in the upstream discussion, which was to emit a runtime warning when os.urandom() is forced to block waiting for the system RNG, so I proposed that as a tweak to the way PEP 524 will be implemented: https://mail.python.org/pipermail/security-sig/2016-August/000105.html That way it can be blocking by default (as specified by PEP 524), but made to raise an error just by setting PYTHONWARNINGS appropriately, *or* patched at build time to add that to the default set of filters in Python/_warnings.c (init_filters). (We could also add it to Lib/warnings.py, but I'm not sure I see any point to doing that, since we never build Python without the warnings accelerator module) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________ python-devel mailing list python-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
