Here's a potentially related issue – apparently Python 3.6 doesn't run
on a CentOS 7 kernel (which would be an issue when running Fedora in
Docker on an EL7 host, or when we try to get py3.6 in EPEL).
https://github.com/rpm-software-management/mock/issues/28
Harris, could you try to reproduce this?
On 08/08/2016 02:59 PM, Nick Coghlan wrote:
On 8 August 2016 at 20:04, Petr Viktorin <pvikt...@redhat.com
<mailto: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.
--
Petr Viktorin
_______________________________________________
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
