Benjamin Peterson added the comment:
You should probably backport _PyRandom_Fini and cleanup the FD like a good
citizen.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21305
___
Alex Gaynor added the comment:
This patch adds the finalizer to the backport -- not sure how I missed this the
first time.
--
Added file: http://bugs.python.org/file36496/backport-urandom.diff
___
Python tracker rep...@bugs.python.org
STINNER Victor added the comment:
@alex: please disable git format in your hgrc, so the bug tracker can create a
review link to Rietveld for your patches.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21305
Alex Gaynor added the comment:
Victor -- new patch is in `hg` format.
--
Added file: http://bugs.python.org/file36497/backport-urandom.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21305
STINNER Victor added the comment:
The third backport-urandom.diff (the one with the review link) looks good to
me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21305
___
Roundup Robot added the comment:
New changeset 3e7f88550788 by Benjamin Peterson in branch '2.7':
PEP 466: backport persistent urandom fd (closes #21305)
http://hg.python.org/cpython/rev/3e7f88550788
--
nosy: +python-dev
resolution: - fixed
stage: needs patch - resolved
status: open -
Alex Gaynor added the comment:
Attached patch backports the persistent FD for urandom.
--
components: +Extension Modules, Interpreter Core
keywords: +needs review, patch
Added file: http://bugs.python.org/file36437/backport-urandom.diff
___
Python
STINNER Victor added the comment:
See also the issue #22181: os.urandom() should use Linux 3.17 getrandom()
syscall.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21305
___
Donald Stufft added the comment:
One of the reasons the PEP was done the way it was done was it allowed you to
write 2/3 compatible code without version checks. Enhancing that class won't
land until 3.5 which is 18+ months away. Further more the os.urandom persistent
FD's already exists and
Nick Coghlan added the comment:
Note that the discussion of this PEP *did* suffer from the language summit
effect where folks that couldn't make it to the summit are missing some of
the context. I believe I included all of the key motivating points in the
PEP itself, but it's still not the same
STINNER Victor added the comment:
The problem is AFAICT there's currently no way to get a file
descriptor to the underlying /dev/urandom (and I don't know how it
works on Windows).
We can reimplement os.urandom in SystemRandom on UNIX to keep the file (fd)
open. The code is very simple,
STINNER Victor added the comment:
(and I don't know how it
works on Windows).
On Windows, the OS CryptoAPI is used and a handle is kept open between
calls to os.urandom. On Windows, I don't think that it's a an issue to keep
a handle open. Handle are not sequential numbers and users don't
Donald Stufft added the comment:
Depleting /dev/urandom isn't actually a thing. /dev/urandom on all modern
*nix OSs uses a fast PRNG which is secure as long as it has received enough
bytes of initial entropy.
--
___
Python tracker
Charles-François Natali added the comment:
Depleting /dev/urandom isn't actually a thing. /dev/urandom on all modern
*nix OSs uses a fast PRNG which is secure as long as it has received enough
bytes of initial entropy.
I didn't say deplete /dev/urandom, I said that when reading from
Donald Stufft added the comment:
I don't think what you're worrying about here is something that has a high
chance of happening, if it even occurs in the wild at all. To be clear in order
for that to matter at all in the context of this ticket, some software would
need to be reading from
Charles-François Natali added the comment:
Using os.urandom is the *right* thing to do for getting random in an
application, but the current implementation effectively punishes people who
use it if their application is highly concurrent.
And I argue that this scenario is almost as likely
Donald Stufft added the comment:
But backporting always has a risk, which has to be balanced.
Sure, which is why a PEP was written, discussed and accepted to find that
balance.
--
___
Python tracker rep...@bugs.python.org
STINNER Victor added the comment:
Please don't backport this feature. We had to wait 20 years before someone
requested the feature, but only a few months before the first user reported an
issue (regression?).
IMO it would be much better to use explicitly a random.SystemRandom instance
which
Donald Stufft added the comment:
Well except random.SystemRandom doesn't keep the file open (At least in 2.7)
and actually it just calls os.urandom under the covers, also it doesn't make it
very nice to get a glob of random bytes.
--
___
Python
Donald Stufft added the comment:
Just verified that 3.x also does not exhibit this behavior with
random.SystemRandom (except implicitly through os.urandom doing it).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21305
STINNER Victor added the comment:
Le 29 avr. 2014 00:22, Donald Stufft rep...@bugs.python.org a écrit :
Well except random.SystemRandom doesn't keep the file open (At least in
2.7) and actually it just calls os.urandom under the covers, also it
doesn't make it very nice to get a glob of random
Charles-François Natali added the comment:
Yes, I'm proposing to enhance this class.
The problem is AFAICT there's currently no way to get a file
descriptor to the underlying /dev/urandom (and I don't know how it
works on Windows).
Also, this would duplicate the work which has already been
Charles-François Natali added the comment:
Like Antoine, I'm really skeptical about the backport: honestly, this change
doesn't bring much in a normal application. To run into the number of open file
descriptors limit (so the scalability aspect), one would need to have *many*
concurrent
Nick Coghlan added the comment:
Yep, it's scary indeed, but such a long lived feature release is a novel
situation that may require some adjustments to our risk management.
However, we can still decide to defer some of the changes until 2.7.8, even
though the notion of backporting them has been
Changes by Tshepang Lekhonkhobe tshep...@gmail.com:
--
nosy: +tshepang
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21305
___
___
Antoine Pitrou added the comment:
Why exactly does it need to be backported? os.urandom under 2.7 works fine.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21305
___
Nick Coghlan added the comment:
It was in the list of security fixes Alex and Donald wanted to reduce
vulnerabilities in 2.x network services, and Guido was OK with backporting
it.
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
It was in the list of security fixes Alex and Donald wanted to reduce
vulnerabilities in 2.x network services, and Guido was OK with backporting
it.
What security issue is there exactly? os.urandom() does a similar thing
in 2.7 and 3.x (it reads from
Alex Gaynor added the comment:
It's not a security issue per-se, but if you're doing many small reads, there's
such an enormous performance and scalability difference that if users run into
an issue, they're likely to work around it by using a non-CS PRNG, and
compromising their application
Antoine Pitrou added the comment:
It's not a security issue per-se, but if you're doing many small
reads, there's such an enormous performance and scalability difference
that if users run into an issue, they're likely to work around it by
using a non-CS PRNG, and compromising their
Antoine Pitrou added the comment:
Note that the 3.4 scheme is not fully debugged yet: issue21207. There is a
reason we don't backport new features!
Regardless, I'm not interested in this, so I'll let you take the risk of
regressions if you want to.
--
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: -pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21305
___
___
Python-bugs-list mailing
New submission from Nick Coghlan:
Tracker issue for the os.urandom persistent file descriptor backport to 2.7
described in PEP 466.
--
messages: 216824
nosy: alex, benjamin.peterson, christian.heimes, dstufft, giampaolo.rodola,
janssen, ncoghlan, pitrou
priority: normal
severity:
Changes by Josh Rosenberg shadowranger+pyt...@gmail.com:
--
nosy: +josh.rosenberg
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21305
___
___
34 matches
Mail list logo
