Christopher Gurnee added the comment:
Option 3 of course wasn't my first choice (given how small the patch is and how
minimal its potential negative impact), but it's certainly better than allowing
an issue to linger in limbo.
Thank you, all.
--
Raymond Hettinger added the comment:
I choose option 3, close as won't fix. The ship for 2.7 sailed a long time
ago. The code for randrange() was designed by Tim Peters and has been in-place
for a decade and half without causing suffering in the world. Also, changing
the type to behavior
Christopher Gurnee added the comment:
There's been no activity on this issue in a few months The three options as
I see it are:
1. Fix it for both randrange and SystemRandom.randrange, breaking randrange's
implied stability between minor versions.
2. Fix it only for
Christopher Gurnee added the comment:
If you have to care about security, you shouldn't use the random module
at all. random.SystemRandom() merely uses a CPRNG as entropy source. But
It also manipulates numbers in ways that may or may not be safe.
I must respectfully disagree with this. The
Christian Heimes added the comment:
IMO it's not a security issue at all. If you have to care about security, you
shouldn't use the random module at all. random.SystemRandom() merely uses a
CPRNG as entropy source. But It also manipulates numbers in ways that may or
may not be safe.
Only
Raymond Hettinger added the comment:
we *still* have no documented guarantees of reproducibility,
so maybe it's safe to go ahead and change this. Raymond?
It is documented here:
https://docs.python.org/3/library/random.html#notes-on-reproducibility
The idea that is that algorithms (and
Mark Dickinson added the comment:
See also #9025, which contains a fix for this exact problem in Python 3.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23974
___
Mark Dickinson added the comment:
In the #9025 discussion, reproducibility was a key concern. Though I note that
despite the comments there, we *still* have no documented guarantees of
reproducibility, so maybe it's safe to go ahead and change this. Raymond?
IMO, the fix from #9025 should
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: +mark.dickinson, rhettinger, serhiy.storchaka
stage: - needs patch
type: - security
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23974
New submission from Christopher Gurnee:
Due to an optimization in random.randrange() only in Python 2, as the
stop-start range approaches 2^53 the output becomes noticeably biased. This bug
also affects random.SystemRandom.
For example, counting the number of even ints in a set of 10^6 random
Skip Montanaro added the comment:
I'm completely unqualified to offer a concrete, expert opinion here, but it
seems like defaulting _maxwidth to 1L52 should work. I have no idea of the
resulting performance implications though.
for bpf in (45, 46, 47, 48, 49, 50, 51, 52, 53):
... print
Christopher Gurnee added the comment:
I shouldn't have called this a rounding error issue, that's not really what it
is.
A smaller example might help.
If I'm given a random int, x, in the range [0, 12), and asked to produce from
it a random int, y, in the range (0,8], I've got (at least?)
12 matches
Mail list logo
