[Security-sig] Take a decision for os.urandom() in Python 3.6
Nick Coghlan
ncoghlan at gmail.com
Sun Aug 7 23:32:55 EDT 2016
On 8 August 2016 at 12:37, Nick Coghlan <ncoghlan at gmail.com> wrote:
> However, from an operations perspective, it means the discussion will move
> downstream to see whether we (Fedora) agree this is the right behaviour for
> the *system* Python, or whether we should patch that to throw the error
> instead of implicitly blocking. Such divergence would be unfortunate (if we
> ultimately decide to go that way), but managing disagreements with
> upstreams about appropriate default behaviour is one of the reasons distros
> *have* the ability to carry patches in the first place.
>
> At the very least, I'll be proposing we do this while the 3.6 beta
> releases are in Fedora Rawhide as a way of gathering objective data about
> the scope of the problem from ABRT (Fedora's automatic bug reporting tool,
> which can automatically collect and submit Python stack traces, but can't
> readily detect system hangs).
>
For folks curious as to what I mean here, this isn't a declaration that
Fedora *is* going to diverge from upstream in terms of the way os.urandom()
behaves in Python 3.6+. Rather, it's a statement that I think we need more
data directly from Fedora's users before deciding whether or not it makes
sense to abide by the cross-platform upstream behaviour, or carry a patch
that changes the behaviour specifically for the system Python installation:
https://lists.fedorahosted.org/archives/list/python-
devel at lists.fedoraproject.org/thread/UAB7JJ5VPW2W2QEERZ4HIQZZB3QMB2H5/
While the interests of Linux distro users and CPython upstream users are
generally pretty well aligned, the alignment isn't 100%, and distros
carrying patches on behalf of their user base is what makes up the
difference.
The Fedora Rawhide experiment I'm proposing in that email to the Fedora
Python list should give us the data we (Fedora) need to decide whether or
not this is one of those cases where it makes sense for us to carry a patch
- if we get zero hits from the exception in ABRT, then it means the default
blocking behaviour should be relatively safe (since people won't be
encountering it), so we can drop the patch before the F26 Beta release, and
Guido will have a solid data point backing up his design instincts. If we
*do* get hits on the exception, then exactly what we do will depend on the
nature of those hits, and in particular whether or not the change is
helping folks find misconfigured Fedora environments they hadn't previously
noticed, or if they're spurious notifications in situations where just
blocking for a few hundred milliseconds would have resolved the problem on
its own (as tested by inserting a "python -c 'import os; os.getrandom(1)"
before whatever application startup is triggering the new exception).
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/security-sig/attachments/20160808/147f5857/attachment-0001.html>
More information about the Security-SIG
mailing list