In terms of API design, I'd prefer a flag to os.urandom() indicating a preference for<div>- blocking</div><div>- raising an exception</div><div>- weaker random bits</div><div><br></div><div>To those still upset by the decision, please read Ted Ts'o's message.<br><br>On Saturday, June 11, 2016, Steven D'Aprano <<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Jun 09, 2016 at 07:52:31PM -0700, Nikolaus Rath wrote:<br>
> On Jun 09 2016, Guido van Rossum <<a href="javascript:;" onclick="_e(event, 'cvml', 'guido@python.org')">guido@python.org</a>> wrote:<br>
> > I don't think we should add a new function. I think we should convince<br>
> > ourselves that there is not enough of a risk of an exploit even if<br>
> > os.urandom() falls back.<br>
><br>
> That will be hard, because you have to consider an active, clever<br>
> adversary.<br>
<br>
We know that there are exploitable bugs from Linux systems due to<br>
urandom, e.g. the Raspberry Pi bug referenced elsewhere in this thread.<br>
<br>
<a href="https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=126892" target="_blank">https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=126892</a><br>
<br>
<br>
> On the other hand, convincing yourself that in practice os.urandom would<br>
> never block unless the setup is super exotic or there is active<br>
> maliciousness seems much easier.<br>
<br>
Not that super exotic. In my day job, I've seen processes hang for five<br>
or ten minutes during boot up, waiting for the OS to collect enough<br>
entropy, although this was not recently and it wasn't involving Python.<br>
But VMs or embedded devices may take a long time to generate entropy. If<br>
the device doesn't have a hardware source of randomness, and isn't<br>
connected to an external source of noise like networking or a user who<br>
habitually fiddles with the mouse, it might take a very long time indeed<br>
to gather entropy...<br>
<br>
If I have understood the concensus, I think we're on the right track:<br>
<br>
(1) os.urandom should do whatever the OS says it should do, which on<br>
Linux is fall back on pseudo-random bytes when the entropy pool hasn't<br>
be initialised yet. It won't block and won't raise.<br>
<br>
(2) os.getrandom will be added to 3.6, and it will block, or possibly<br>
raise, whichever the caller specifies.<br>
<br>
(3) The secrets module in 3.6 will stop relying on os.urandom, and use<br>
os.getrandom. It may provide a switch to choose between blocking and<br>
non-blocking (raise an exception) behaviour. It WON'T fall back to<br>
predictable non-crypto bytes (unless the OS itself is completely<br>
broken).<br>
<br>
(4) random will continue to seed itself from os.urandom, because it<br>
doesn't care if urandom provides degraded randomness. It just needs to<br>
be better than using the time as seed.<br>
<br>
(5) What about random.SysRandom? I think it should use os.getrandom.<br>
<br>
(6) A bunch of stuff will happen to make the hash randomisation not<br>
break when systemd runs Python scripts early in the boot process, but I<br>
haven't been paying attention to that part :-)<br>
<br>
Is this a good summary of where we are at?<br>
<br>
<br>
<br>
--<br>
Steve<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'Python-Dev@python.org')">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" target="_blank">https://mail.python.org/mailman/options/python-dev/guido%40python.org</a><br>
</blockquote></div><br><br>-- <br>--Guido (mobile)<br>