[Security-sig] Take a decision for os.urandom() in Python 3.6

[Nick Coghlan]

On 8 August 2016 at 09:41, Victor Stinner <victor.stinner at gmail.com> wrote:

> 2016-08-08 1:11 GMT+02:00 Guido van Rossum <guido at python.org>:
> > Sorry, PEP 524 is accepted, and PEP 522 is rejected. Let os.urandom()
> > be blocking, and let os.getrandom() be added. Congrats, Victor!
>
> Ok. I changed the status of my PEP 524 from Draft to Accepted. I will
> now start to work on the implementation.
>
> For Nick's PEP 522, I don't know if its status should be updated to
> Rejected or Superseded (by the PEP 524). I prefer to let Nick changes
> the status of his PEP ;-)
>

Rejected, but I'm still quite concerned by the lack of operator input into
this discussion, particularly when we're going against what the Linux
kernel developers themselves decided to do - Ted T'so flicked the
equivalent switch for the Linux kernel (to make /dev/urandom blocking) and
doing so caused some of the systems in their CI fleet to fail.

>From a pure developer point of view, I completely understand Guido's
perspective that blocking feels safer than risking throwing an exception,
as well as wanting to be able to call the issue done and not worry about it
anymore.

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).

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/29e43171/attachment.html>