On 8 August 2016 at 13:10, Nick Coghlan <ncoghlan(a)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.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia