[issue27288] secrets should use getrandom() on Linux

[Nick Coghlan]

Nick Coghlan added the comment:

PEP 524 has been implemented for 3.6b1 in #27776, so os.urandom() itself will 
now do the right thing for cryptographic use cases on Linux.

--
nosy: +ncoghlan
resolution:  -> out of date
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27288] secrets should use getrandom() on Linux

[Donald Stufft]

Changes by Donald Stufft :


--
nosy:  -dstufft

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27288] secrets should use getrandom() on Linux

[Ned Deily]

Ned Deily added the comment:

Setting this to "deferred blocker" priority to note that it needs to be 
resolved prior to feature code cutoff for 3.6.0, which is at 3.6.0b1 currently 
planned for 2016-09-07.

--
priority: release blocker -> deferred blocker

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27288] secrets should use getrandom() on Linux

[Jelle Zijlstra]

Jelle Zijlstra added the comment:

I'm interested in implementing this for 3.6, but I'm not sure exactly what the 
changes are that were decided upon. Is the following accurate?

1. Nothing changes in os (all the necessary changes were made in 3.5.2 already).
2. On Linux 3.17+ only, we add a new extension module called _secrets that 
provides a wrapper around the getrandom() system call and nothing else. I'll 
have to figure out whether to make the extension module just not exist all on 
non-Linux OSs (are there any existing extension modules that only exist on one 
OS?), or whether to make it empty on non-Linux. _secrets.getrandom() will look 
like def getrandom(buflen: int, flags: int) -> bytes.
3. We change secrets.SystemRandom so that on Linux 3.17+ only, it subclasses 
random.SystemRandom to use _secrets.getrandom() instead of os.urandom(). We 
will not pass in any flags to getrandom() (so we read from /dev/urandom and 
block until there is sufficient entropy). To make the subclassing easier, we 
may want to change random.SystemRandom to have a private method for calling 
os.urandom. (Currently, both of its methods call os.urandom directly.)
4. Similarly, we change secrets.token_bytes to use _secrets.getrandom(). Other 
functions in secrets.py won't need to change since they use 
secrets.SystemRandom or secrets.token_bytes.
5. _secrets and _secrets.getrandom will remain private and undocumented.

--
nosy: +Jelle Zijlstra

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27288] secrets should use getrandom() on Linux

[Brett Cannon]

Brett Cannon added the comment:

It should be mentioned that Guido really doesn't like the idea of 
os.getrandom() as it exposes stuff where we would rather simply tell people to 
use the secrets module.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27288] secrets should use getrandom() on Linux

[Tim Peters]

Tim Peters added the comment:

I think it's clear Guido would say "#1".  The thrust of all his comments to 
date is that it was a mistake to change the semantics of os.urandom() on Linux 
(and one other platform? don't really care), and that in 3.6+ only `secrets` 
should _try_ to supply possibly-blocking behavior on Linux.

Indeed, even in 3.6+ he doesn't want to expose the new-ish getrandom() 
directly.  Today he said:

"""
So what should the secrets module use? Let's make that part an extension module.
"""

So he feels strongly enough about this as to recommend a teensy private C 
extension module for secrets.py alone to get at the platform getrandom() (if 
any - of course it needs to fall back to os.urandom() on other platforms).

"""
The main thing that I want to avoid is that people start cargo-culting whatever 
the secrets module uses rather than just using the secrets module. Having it 
redundantly available as os.getrandom() is just begging for people to show off 
how much they know about writing secure code. 
"""

Whenever he starts taking that tone, his mind is made up for good ;-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27288] secrets should use getrandom() on Linux

[Brett Cannon]

Brett Cannon added the comment:

Based on the documentation of random.SysRandom I think it comes down to #1. 
Perhaps the secrets documentation simply shouldn't mention the random module 
beyond how it's different? Then any use of the random module by the secrets 
module is an implementation detail that people can never rely on because we 
never said anything in the docs about it and clearly say "we do whatever is 
necessary to get you the most random bytes possible, backwards-compat be damned 
in how we pull it off".

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27288] secrets should use getrandom() on Linux

[Cory Benfield]

Changes by Cory Benfield :


--
nosy: +Lukasa

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27288] secrets should use getrandom() on Linux

[Steven D'Aprano]

Steven D'Aprano added the comment:

I don't want to start another huge thread on python-dev unless really 
necessary. What should happen to random.SystemRandom?

(1) nothing, it stays as it is, and if ``secrets`` needs better, it can 
subclass it;

(2) it changes to use ``os.getrandom``, and then ``secrets`` can continue to 
expose ``SystemRandom``.

If it comes to a vote, I'm +1 on option 2.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27288] secrets should use getrandom() on Linux

[Brett Cannon]

Changes by Brett Cannon :


--
nosy: +steven.daprano

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27288] secrets should use getrandom() on Linux

[Tim Peters]

Tim Peters added the comment:

It was a primary purpose of `secrets` to be a place where security best 
practices could be implemented, and changed over time, with no concern about 
backward compatibility for people who don't use it.

So if `secrets` needs to supply a class with all the methods of random.Random, 
it should derive its own subclass (or derive from random.SystemRandom, and 
override the only two methods that explicitly invoke _urandom() - everything 
else ends up using .random() or .getrandbits()).

--
nosy: +tim.peters

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27288] secrets should use getrandom() on Linux

[Donald Stufft]

Donald Stufft added the comment:

As an additional aside, the documentation of secrets references the 
documentation of random.py for it's secrets.SystemRandom class, however 
random.py docouments random.SystemRandom as using os.urandom.

So the documentation for secrets.SystemRandom should be disentangled from the 
documentation of random.SystemRandom so that it can choose to use the stronger 
randomness function (or random.SystemRandom should be adapted to use the 
stronger randomness function, or both things).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27288] secrets should use getrandom() on Linux

[Donald Stufft]

New submission from Donald Stufft:

In 3.5.0 and 3.5.1 os.urandom will, where available, use the getrandom() to 
block rather than get insecure random from the urandom pool on Linux. In 3.5.2 
this change is reverted so that os.urandom will return possibly predictable 
random numbers instead of blocking waiting for /dev/urandom to be intialized.

However, secrets.py is a module which is explicitly for getting 
cryptographically safe data for, and reverting that change means that the 
functions in this module are no longer cryptographically safe on Linux if they 
are called early enough in the boot process. Thus, secrets.py should be 
modified so that it no longer uses os.urandom on systems where there is a 
better source of randomness available-- namely getrandom() set to block on 
Linux.

--
messages: 268147
nosy: brett.cannon, dstufft, ned.deily
priority: release blocker
severity: normal
status: open
title: secrets should use getrandom() on Linux
type: security
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com