[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits? (original) (raw)

Nathaniel Smith njs at pobox.com
Sun Jun 12 21:53:54 EDT 2016

On Sun, Jun 12, 2016 at 4:28 PM, Theodore Ts'o <tytso at mit.edu> wrote:

P.S. BTW, I probably won't change the behaviour of /dev/urandom to make it be blocking. Before I found out about Pyhton Bug #26839, I actually had patches that did make /dev/urandom blocking, and they were planned to for the next kernel merge window. But ultimately, the reason why I won't is because there is a set of real users (Debian Stretch users on Amazon AWS and Google GCE) for which if I changed how /dev/urandom worked, then I would be screwing them over, even if Python 3.5.2 falls back to /dev/urandom. It's not a problem for bare metal hardware and cloud systems with virtio-rng; I have patches that will take care of those scenarios.

Unfortunately, both AWS and GCE don't support virtio-rng currently, and as much as some poeple are worried about the hypothetical problems of stupidly written/deployed Python scripts that try to generate long-term secrets during early boot, weighed against the very real prospect of user lossage on two of the most popular Cloud environments out there --- it's simply no contest.

Speaking of full-stack perspectives, would it affect your decision if Debian Stretch were made robust against blocking /dev/urandom on AWS/GCE? Because I think we could find lots of people who would be overjoyed to fix Stretch before the next merge window even opens (AFAICT the quick fix is literally a 1 line patch), if that allowed the blocking /dev/urandom patches to go in upstream...

(It looks like Jessie isn't affected, because while Jessie does provide a systemd-cron package for those who decide to install it, Jessie's systemd-cron is still using python2, python2 doesn't have hash randomization so it doesn't touch /dev/urandom at startup, and systemd-cron doesn't have any code that would trigger access to /dev/urandom otherwise. It looks like Xenial is affected, because they ship systemd-cron with python3, but their python3 is still unconditionally using getrandom() in blocking mode, so they need to patch that regardless, and could just as easily make it robust against blocking /dev/urandom at the same time. I don't understand the RPM world as well, but I can't find any evidence that Fedora or SuSE ship systemd-cron at all.)

-n

-- Nathaniel J. Smith -- https://vorpus.org

More information about the Python-Dev mailing list