On 8 August 2016 at 09:41, Victor Stinner <victor.stin...@gmail.com> wrote:
> 2016-08-08 1:11 GMT+02:00 Guido van Rossum <gu...@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 | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig
