<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jun 11, 2016 at 12:53 PM, Larry Hastings <span dir="ltr"><<a href="mailto:larry@hastings.org" target="_blank">larry@hastings.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<div><br>
On 06/11/2016 11:30 AM, Donald Stufft wrote:<br>
</div>
<blockquote type="cite">
<div>The problem is that someone writing software that does
os.urandom(block=True) or os.urandom(exception=True) which gets
some bytes doesn’t know if it got back cryptographically secure
random because Python called getrandom() or if it got back
cryptographically secure random because it called /dev/urandom
and that gave it secure random because it’s on a platform that
defines that as always returning secure or because it’s on Linux
and the urandom pool is initialized or if it got back some
random bytes that are not cryptographically secure because it
fell back to reading /dev/urandom on Linux prior to the pool
being initialized.<br>
</div>
</blockquote>
<br></span>
Let me jump in tangentially to say: I think os.urandom(block=True)
is simply a bad API. On FreeBSD and OpenBSD, /dev/urandom may
block, and you don't have a choice. On OS X, /dev/urandom will
never block, and you don't have a choice. In Victor's initial patch
where he proposed it, the flag was accepted on all platforms but
only affected its behavior on Linux and possibly Solaris. I think
it's bad API design to have a flag that seems like it would be
meaningful on multiple platforms, but in practice is useful only in
very limited circumstances. If this were old code, or behavior we
inherited from the platform and we were making the best of a bad
situation, that'd be one thing. But this is a proposed new API and
I definitely think we can do better.<br>
<br>
As I understand the proposed semantics for
os.urandom(exception=True), I feel it falls into the same trap
though not to the same degree.<br>
<br>
Of course, both flags break backwards-compatibility if they default
to True, and I strongly disagree with .<br>
<br>
It's far better in my opinion to keep the os module as a thin shell
over platform functionality. That makes Python's behavior more
predictable on a platform-by-platform basis. So I think the best
approach here is to add os.getrandom() as a thin shell over the
local getrandom() (if any).<br></div></blockquote></div><br></div><div class="gmail_extra">OK, the flags are unpopular, so let's forget about them.<br><br></div><div class="gmail_extra">But I find an os.getrandom() that only exists on those (few?) platforms that support it a nuisance too -- this just encourages cargo cult code that's unnecessarily complicated and believed to be secure without anybody ever verifying.<br><br></div><div class="gmail_extra">I'd like to consider what people freak out about.<br><br></div><div class="gmail_extra">- You could freak out about blocking<br><br></div><div class="gmail_extra">- You could freak out about getting slightly less random bits<br><br></div><div class="gmail_extra">- You could freak out about supporting Python 3.5 and earlier<br><br></div><div class="gmail_extra">- You could freak out about supporting all platforms<br><br></div><div class="gmail_extra">You could also freak out about combinations of the above, but that gets complicated and you should probably consider that you're over-constraining matters. If you freak out about all at once (or both the first and the second bullet) you should consider a career change.<br><br></div><div class="gmail_extra">If you don't freak out about any of these (meaning you're happy with Python 3.6+) you should use the secrets module.<br><br></div><div class="gmail_extra">If you freak out about support for older Python versions, try the secrets module first and fall back to os.urandom() -- there really isn't any other choice.<br><br></div><div class="gmail_extra">If you freak out about getting slightly less random bits you should probably do a complete security assessment of your entire stack and fix the OS and Python version, and use the best you can get for that combination. You may not want to rely on the standard library at all.<br><br></div><div class="gmail_extra">If you freak out about blocking you're probably on a specific platform, and if that platform is Linux, you're in luck: use os.urandom() and avoid Python 3.5.0 and 3.5.1. On other platforms you're out of luck.<br><br></div><div class="gmail_extra">So I still don't see why we need os.getrandom() -- it has nothing to recommend it over the secrets module (since both won't happen before 3.6).<br><br></div><div class="gmail_extra">So what should the secrets module use? Let's make that part an extension module.<br></div><br><div class="gmail_extra">-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>