On Fri, Jun 10, 2016 at 11:29 AM, David Mertz <me...@gnosis.cx> wrote: > This is fairly academic, since I do not anticipate needing to do this > myself, but I have a specific question. I'll assume that Python 3.5.2 will > go back to the 2.6-3.4 behavior in which os.urandom() never blocks on Linux. > Moreover, I understand that the case where the insecure bits might be > returned are limited to Python scripts that run on system initialization on > Linux. > > If I *were* someone who needed to write a Linux system initialization script > using Python 3.5.2, what would the code look like. I think for this use > case, requiring something with a little bit of "code smell" is fine, but I > kinda hope it exists at all.
Good question. And going back to Larry's original e-mail, where he said-- On Thu, Jun 9, 2016 at 4:25 AM, Larry Hastings <la...@hastings.org> wrote: > THE PROBLEM > ... > The issue author had already identified the cause: CPython was blocking on > getrandom() in order to initialize hash randomization. On this fresh > virtual machine the entropy pool started out uninitialized. And since the > only thing running on the machine was CPython, and since CPython was blocked > on initialization, the entropy pool was initializing very, very slowly. it seems to me that you'd want such a solution to have code that causes the initialization of the entropy pool to be sped up so that it happens as quickly as possible (if that is even possible). Is it possible? (E.g. by causing the machine to start doing things other than just CPython?) --Chris _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
