On 8 August 2016 at 20:04, Petr Viktorin <pviktori(a)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 | ncoghlan(a)gmail.com | Brisbane, Australia