On 08/08/2016 06:09 AM, Nick Coghlan wrote:
On 8 August 2016 at 13:10, Nick Coghlan <ncoghlan(a)gmail.com
<mailto:ncoghlan@gmail.com>> wrote:
Accordingly, what I propose we do is as follows:
1. Raise the concern in the F26 system-wide change proposal for
migrating to Python 3.6
2. Apply the patch when the 3.6 beta releases are added to Fedora
Rawhide
3. Decide whether or not to keep the patch based on ABRT results and
other feedback on the Rawhide builds.
Note that if the feedback on Rawhide shows that the change is
helping people to find and diagnose VMs and hardware with improperly
seeded entropy pools, that's a *good* thing: this proposed change is
replacing Python 3.5's "/dev/urandom and os.urandom() may silently
return statistically less-than-fully-random random numbers if the
kernel entropy pool isn't seeded properly" with "os.urandom() will
fail noisily in those cases, so you can either switch to the random
module, or fix your entropy pool seeding".
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.
--
Petr Viktorin