[issue13703] Hash collision security issue

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue13703] Hash collision security issue

Terry J. Reedy added the comment: Because today's spammer, whose message was removed, deleted us all. Restoring the version to 3.3 is not possible. -- ___ Python tracker ___

[issue13703] Hash collision security issue

Guido van Rossum added the comment: Hey Erlend, why did you add so many people to the nosy list of this old issue? On Thu, Nov 4, 2021 at 07:33 Erlend E. Aasland wrote: > > Change by Erlend E. Aasland : > > > -- > components: +Interpreter Core -Argument Clinic > nosy: +Arach, Arfreve

[issue13703] Hash collision security issue

Change by Erlend E. Aasland : -- components: +Interpreter Core -Argument Clinic nosy: +Arach, Arfrever, Huzaifa.Sidhpurwala, Jim.Jewett, Mark.Shannon, PaulMcMillan, Zhiping.Deng, alex, barry, benjamin.peterson, christian.heimes, cvrebert, dmalcolm, eric.araujo, eric.snow, fx5, georg.b

[issue13703] Hash collision security issue

Change by Erlend E. Aasland : -- Removed message: https://bugs.python.org/msg405707 ___ Python tracker ___ ___ Python-bugs-list mail

[issue13703] Hash collision security issue

Ahmed Sayeed added the comment: In collect_register() function of arc-linux-tdep.c, the "eret" http://www-look-4.com/travel/london/ (exception return) register value is not being reported correctly. Background: https://komiya-dental.com/shopping/buy-android/ When asked for the "pc" value, we

[issue13703] Hash collision security issue

Gregory P. Smith added the comment: I believe so. This is in all of the release candidates. The expat/xmlparse.c hash collision DoS issue is being handled on its own via http://bugs.python.org/issue14234. -- resolution: -> fixed status: open -> closed __

[issue13703] Hash collision security issue

STINNER Victor added the comment: Can we close this issue? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue13703] Hash collision security issue

Jon Vaughan added the comment: Victor - yes that was it; a mixture of a 2.7.2 virtual env and 2.7.3. Apologies for any nuisance caused. -- ___ Python tracker ___ _

[issue13703] Hash collision security issue

STINNER Victor added the comment: > FWIW I upgraded to ubuntu pangolin beta over the weekend, > which includes 2.7.3rc1, ... > > File "/usr/lib/python2.7/random.py", line 47, in >from os import urandom as _urandom > ImportError: cannot import name urandom It looks like you are using rando

[issue13703] Hash collision security issue

Jon Vaughan added the comment: FWIW I upgraded to ubuntu pangolin beta over the weekend, which includes 2.7.3rc1, and I'm also experiencing a problem with urandom. File "/usr/lib/python2.7/email/utils.py", line 27, in import random File "/usr/lib/python2.7/random.py", line 47, in

[issue13703] Hash collision security issue

Changes by Kurt Seifried : -- nosy: -kseifr...@redhat.com ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue13703] Hash collision security issue

Kurt Seifried added the comment: I have assigned CVE-2012-1150 for this issue as per http://www.openwall.com/lists/oss-security/2012/03/10/3 -- nosy: +kseifr...@redhat.com ___ Python tracker _

[issue13703] Hash collision security issue

Chris Rebert added the comment: The Design and History FAQ (will) need a minor corresponding update: http://docs.python.org/dev/faq/design.html#how-are-dictionaries-implemented -- ___ Python tracker __

[issue13703] Hash collision security issue

Roger Serwy added the comment: It was a false alarm. I didn't recompile python before running it with the latest /Lib files. My apologies. -- ___ Python tracker ___ ___

[issue13703] Hash collision security issue

Benjamin Peterson added the comment: Can you paste the error you're getting? 2012/2/26 Roger Serwy : > > Roger Serwy added the comment: > > After pulling the latest code, random.py no longer works since it tries to > import urandom from os on both 3.3 and 2.7. > > -- > nosy: +serwy >

[issue13703] Hash collision security issue

Roger Serwy added the comment: After pulling the latest code, random.py no longer works since it tries to import urandom from os on both 3.3 and 2.7. -- nosy: +serwy ___ Python tracker ___

[issue13703] Hash collision security issue

Changes by Chris Rebert : -- nosy: +cvrebert ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue13703] Hash collision security issue

Barry A. Warsaw added the comment: Never mind about sys.hash_seed. See my follow up in python-dev. I consider this issue is closed wrt the 2.6 branch. -- ___ Python tracker _

[issue13703] Hash collision security issue

Barry A. Warsaw added the comment: I have to amend my suggestion about sys.flags.hash_randomization. It needs to be non-zero even if $PYTHONHASHSEED is given instead of -R. Many other flags that also have envars work the same way, e.g. -O and $PYTHONOPTIMIZE. So hash_randomization has to w

[issue13703] Hash collision security issue

Gregory P. Smith added the comment: +1 to what barry and __ap__ discussed and settled on. -- ___ Python tracker ___ ___ Python-bugs-l

[issue13703] Hash collision security issue

Barry A. Warsaw added the comment: On Feb 21, 2012, at 09:48 AM, Marc-Andre Lemburg wrote: >The flag should probably be removed - simply because >the env var is not a flag, it's a configuration parameter. > >Exposing the seed value as sys.hashseed would be better and more useful >to application

[issue13703] Hash collision security issue

Barry A. Warsaw added the comment: On Feb 21, 2012, at 09:48 AM, Marc-Andre Lemburg wrote: >Exposing the seed value as sys.hashseed would be better and more useful >to applications. That makes the most sense to me. -- ___ Python tracker

[issue13703] Hash collision security issue

Antoine Pitrou added the comment: > That is a good question. I don't really care either way, but let's > say +0 for turning it off when seed == 0. +1 -- ___ Python tracker ___

[issue13703] Hash collision security issue

Marc-Andre Lemburg added the comment: STINNER Victor wrote: > > STINNER Victor added the comment: > >> Question: Should sys.flags.hash_randomization be True (1) when >> PYTHONHASHSEED=0? It is now. >> >> Saying yes "working as intended" is fine by me. > > It is documented that PYTHONHASHSE

[issue13703] Hash collision security issue

Marc-Andre Lemburg added the comment: Gregory P. Smith wrote: > > Gregory P. Smith added the comment: > > Question: Should sys.flags.hash_randomization be True (1) when > PYTHONHASHSEED=0? It is now. The flag should probably be removed - simply because the env var is not a flag, it's a con

[issue13703] Hash collision security issue

STINNER Victor added the comment: > Question: Should sys.flags.hash_randomization be True (1) when > PYTHONHASHSEED=0?  It is now. > > Saying yes "working as intended" is fine by me. It is documented that PYTHONHASHSEED=0 disables the randomization, so sys.flags.hash_randomization must be Fals

[issue13703] Hash collision security issue

Georg Brandl added the comment: That is a good question. I don't really care either way, but let's say +0 for turning it off when seed == 0. -R still needs to be made default in 3.3 - that's one reason this issue is still open. -- ___ Python trac

[issue13703] Hash collision security issue

Gregory P. Smith added the comment: Question: Should sys.flags.hash_randomization be True (1) when PYTHONHASHSEED=0? It is now. Saying yes "working as intended" is fine by me. sys.flags.hash_randomization seems to simply indicate that doing something with the hash seed was explicitly specif

[issue13703] Hash collision security issue

Gregory P. Smith added the comment: The bug report is the easiest thing to search for and follow when checking when something is resolved so it is nice to have a link to the relevant patch(es) for each branch. I just wanted to note the major commit here so that all planned branches had a not

[issue13703] Hash collision security issue

Georg Brandl added the comment: But since our workflow is such that commits in X.Y branches always show up in X.Y+1, it doesn't really matter. -- ___ Python tracker ___ ___

[issue13703] Hash collision security issue

Éric Araujo added the comment: Yep, the bot only looks at commit messages, it does not inspect merges or other topographical information. That’s why some of us make sure to repeat bug numbers in our merge commit messages. -- ___ Python tracker

[issue13703] Hash collision security issue

Gregory P. Smith added the comment: Roundup Robot didn't seem to notice it, but this has also been committed in 2.7: http://hg.python.org/cpython/rev/a0f43f4481e0 -- ___ Python tracker ___

[issue13703] Hash collision security issue

Roundup Robot added the comment: New changeset 6b7704fe1be1 by Barry Warsaw in branch '2.6': - Issue #13703: oCERT-2011-003: add -R command-line option and PYTHONHASHSEED http://hg.python.org/cpython/rev/6b7704fe1be1 -- ___ Python tracker

[issue13703] Hash collision security issue

Roundup Robot added the comment: New changeset ed76dc34b39d by Georg Brandl in branch 'default': Merge 3.2: Issue #13703 plus some related test suite fixes. http://hg.python.org/cpython/rev/ed76dc34b39d -- ___ Python tracker

[issue13703] Hash collision security issue

Roundup Robot added the comment: New changeset 4a31f6b11e7a by Georg Brandl in branch '3.2': Merge from 3.1: Issue #13703: add a way to randomize the hash values of basic types (str, bytes, datetime) http://hg.python.org/cpython/rev/4a31f6b11e7a --

[issue13703] Hash collision security issue

Roundup Robot added the comment: New changeset f4b7ecf8a5f8 by Georg Brandl in branch '3.1': Issue #13703: add a way to randomize the hash values of basic types (str, bytes, datetime) http://hg.python.org/cpython/rev/f4b7ecf8a5f8 -- nosy: +python-dev __

[issue13703] Hash collision security issue

Benjamin Peterson added the comment: +1 for fixing all tests. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue13703] Hash collision security issue

Antoine Pitrou added the comment: > With PYTHONHASHSEED=random, at least those tests still fail: > test_descr test_json test_set test_ttk_textonly test_urllib > > Do we want to fix them in 3.1? I don't know, but we'll have to fix them in 3.2 to avoid breaking the buildbots. So we might also fi

[issue13703] Hash collision security issue

Éric Araujo added the comment: > With PYTHONHASHSEED=random, at least those tests still fail: > test_descr test_json test_set test_ttk_textonly test_urllib > > Do we want to fix them in 3.1? It the failures are caused by the test depending on dict order (i.e. not real bugs, not changed behavio

[issue13703] Hash collision security issue

Georg Brandl added the comment: New patch fixes failures due to sys.flags backwards compatibility. With PYTHONHASHSEED=random, at least those tests still fail: test_descr test_json test_set test_ttk_textonly test_urllib Do we want to fix them in 3.1? -- Added file: http://bugs.python.

[issue13703] Hash collision security issue

Changes by Georg Brandl : Removed file: http://bugs.python.org/file24562/hash-patch-3.1-gb.patch ___ Python tracker ___ ___ Python-bugs-list m

[issue13703] Hash collision security issue

Georg Brandl added the comment: New version, with the hope that it gets a "review" link. -- Added file: http://bugs.python.org/file24562/hash-patch-3.1-gb.patch ___ Python tracker _

[issue13703] Hash collision security issue

Changes by Georg Brandl : Removed file: http://bugs.python.org/file24561/hash-patch-3.1-gb.diff ___ Python tracker ___ ___ Python-bugs-list ma

[issue13703] Hash collision security issue

Georg Brandl added the comment: Attaching reviewed version for 3.1 with unified env var PYTHONHASHSEED and encompassing Antoine's and Greg's review comments. -- Added file: http://bugs.python.org/file24561/hash-patch-3.1-gb.diff ___ Python tracker

[issue13703] Hash collision security issue

Martin v. Löwis added the comment: > Frankly, other short strings may give away even more, because you can > put several into the same dict. Please don't make such claims without some reasonable security analysis: how *exactly* would you derive the hash seed when you have the hash values of all

[issue13703] Hash collision security issue

Jim Jewett added the comment: On Mon, Feb 13, 2012 at 3:37 PM, Dave Malcolm added the comment: >  * added comments about the specialcasing of length 0: >    /* >      We make the hash of the empty string be 0, rather than using >      (prefix ^ suffix), since this slightly obfuscates the hash

[issue13703] Hash collision security issue

Marc-Andre Lemburg added the comment: Dave Malcolm wrote: > [new patch] Please change how the env vars work as discussed earlier on this ticket. Quick summary: We only need one env var for the randomization logic: PYTHONHASHSEED. If not set, 0 is used as seed. If set to a number, a fixed seed

[issue13703] Hash collision security issue

Gregory P. Smith added the comment: Comments to be addressed added on the code review. -- ___ Python tracker ___ ___ Python-bugs-list

[issue13703] Hash collision security issue

Gregory P. Smith added the comment: Should -R be required to take a parameter specifying "on" or "off" so that code using a #! line continues to work as specified across the a change in default behavior when upgrading from 3.2 to 3.3? #!/usr/bin/python3 -R on #!/usr/bin/python3 -R off In 3.3 i

[issue13703] Hash collision security issue

Dave Malcolm added the comment: I'm not quite sure how that would interact with the -R command-line option for enabling randomization. The changes to the docs in the latest patch clarifies the meaning of what I've implemented (I hope). My view is that we should simply enable hash randomization

[issue13703] Hash collision security issue

Jim Jewett added the comment: On Fri, Feb 10, 2012 at 6:02 PM, STINNER Victor >  - PYTHONHASHSEED doc is not clear: it should be mentionned > that the variable is ignored if PYTHONHASHRANDOMIZATION > is not set *That* is why this two-envvar solution bothers me. PYTHONHASHSEED has to be a stri

[issue13703] Hash collision security issue

STINNER Victor added the comment: Review of add-randomization-(...).patch: - there is a missing ")" in the doc, near "the types covered by the :option:`-R` option (or its equivalent, :envvar:`PYTHONHASHRANDOMIZATION`." - get_hash() in test_hash.py fails completly on Windows: Windows requires

[issue13703] Hash collision security issue

Gregory P. Smith added the comment: Thanks for reviewing Benjamin. I'm also reviewing this today. Sorry for the delay! BTW, like Schadenfreude? A hash collision DOS issue "fix" patch for PHP5 was done poorly and introduced a new security vulnerability that was just used to let script kiddies

[issue13703] Hash collision security issue

Benjamin Peterson added the comment: So modulo my (small) review comments, David's patches are ready to go in. -- ___ Python tracker ___

[issue13703] Hash collision security issue

Marc-Andre Lemburg added the comment: Dave Malcolm wrote: > > If anyone is aware of an attack via numeric hashing that's actually > possible, please let me know (privately). I believe only specific apps > could be affected, and I'm not aware of any such specific apps. I'm not sure what you'd

[issue13703] Hash collision security issue

Dave Malcolm added the comment: On Mon, 2012-02-06 at 23:00 +, Marc-Andre Lemburg wrote: > Marc-Andre Lemburg added the comment: > > Alex Gaynor wrote: > > There's no need to cover any container types, because if their constituent > > types are securely hashable then they will be as well.

[issue13703] Hash collision security issue

Marc-Andre Lemburg added the comment: Alex Gaynor wrote: > There's no need to cover any container types, because if their constituent > types are securely hashable then they will be as well. And of course if > the constituent types are unsecure then they're directly vulnerable. I wouldn't nece

[issue13703] Hash collision security issue

Alex Gaynor added the comment: On Mon, Feb 6, 2012 at 5:04 PM, Marc-Andre Lemburg wrote: > > Marc-Andre Lemburg added the comment: > > Alex Gaynor wrote: > > Can't randomization just be applied to integers as well? > > A simple seed xor'ed with the hash won't work, since the attacks > I posted

[issue13703] Hash collision security issue

Marc-Andre Lemburg added the comment: Alex Gaynor wrote: > Can't randomization just be applied to integers as well? A simple seed xor'ed with the hash won't work, since the attacks I posted will continue to work (just colliding on a different hash value). Using a more elaborate hash algorithm

[issue13703] Hash collision security issue

Dave Malcolm added the comment: > Can't randomization just be applied to integers as well? > It could, but see http://bugs.python.org/issue13703#msg151847 Would my patches be more or less likely to get reviewed with vs without an extension of randomization to integers? -- __

[issue13703] Hash collision security issue

Alex Gaynor added the comment: On Mon, Feb 6, 2012 at 4:41 PM, Marc-Andre Lemburg wrote: > > Marc-Andre Lemburg added the comment: > > Gregory P. Smith wrote: > > > > Gregory P. Smith added the comment: > > > >> > >>> The release managers have pronounced: > >>> http://mail.python.org/pipermai

[issue13703] Hash collision security issue

Marc-Andre Lemburg added the comment: Gregory P. Smith wrote: > > Gregory P. Smith added the comment: > >> >>> The release managers have pronounced: >>> http://mail.python.org/pipermail/python-dev/2012-January/115892.html >>> Quoting that email: 1. Simple hash randomization is the way to

[issue13703] Hash collision security issue

Gregory P. Smith added the comment: > > > The release managers have pronounced: > > http://mail.python.org/pipermail/python-dev/2012-January/115892.html > > Quoting that email: > >> 1. Simple hash randomization is the way to go. We think this has the > >> best chance of actually fixing the probl

[issue13703] Hash collision security issue

Marc-Andre Lemburg added the comment: Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > >>> Right, but that doesn't contradict what I wrote about adding >>> env vars to fix a seed and optionally enable using a random >>> seed, or adding collision counting as extra protection for >

[issue13703] Hash collision security issue

Antoine Pitrou added the comment: > > Right, but that doesn't contradict what I wrote about adding > > env vars to fix a seed and optionally enable using a random > > seed, or adding collision counting as extra protection for > > cases that are not addressed by the hash seeding, such as > > e.g.

[issue13703] Hash collision security issue

Marc-Andre Lemburg added the comment: Marc-Andre Lemburg wrote: > Dave Malcolm wrote: >> The release managers have pronounced: >> http://mail.python.org/pipermail/python-dev/2012-January/115892.html >> Quoting that email: >>> 1. Simple hash randomization is the way to go. We think this has the >

[issue13703] Hash collision security issue

Marc-Andre Lemburg added the comment: Dave Malcolm wrote: > >>> So the overhead in startup time is not an issue? >> >> It is an issue. Not only in terms of startup time, but also >... >> because randomization per default makes Python behave in >> non-deterministc ways - which is not what you w

[issue13703] Hash collision security issue

Jim Jewett added the comment: On Mon, Feb 6, 2012 at 1:53 PM, Frank Sievertsen wrote: >>> BTW: If you set the limit N to e.g. 100 (which is reasonable given >>> Victor's and my tests), >> So it would take around 3Mb to cause a minute's delay... > How did you calculate that? 16 bytes/entry *

[issue13703] Hash collision security issue

Dave Malcolm added the comment: On Mon, 2012-02-06 at 10:20 +, Marc-Andre Lemburg wrote: > Marc-Andre Lemburg added the comment: > > STINNER Victor wrote: > > > > STINNER Victor added the comment: > > > >> In a security fix release, we shouldn't change the linkage procedures, > >> so I

[issue13703] Hash collision security issue

Marc-Andre Lemburg added the comment: Jim Jewett wrote: > >> BTW: If you set the limit N to e.g. 100 (which is reasonable given >> Victor's and my tests), > > Agreed. Frankly, I think 5 would be more than reasonable so long as > there is a fallback. > >> the time it takes to process one of t

[issue13703] Hash collision security issue

Frank Sievertsen added the comment: > Agreed; it tops out with a constant, but if it takes only 16 bytes of > input to force another run through a 1000-long collision, that may > still be too much leverage. You should prepare the dict so that you have the collisions-run with a one-byte string

[issue13703] Hash collision security issue

Jim Jewett added the comment: On Mon, Feb 6, 2012 at 12:07 PM, Marc-Andre Lemburg wrote: > > Marc-Andre Lemburg added the comment: > > Jim Jewett wrote: >> The problematic case is, roughly, >> (1)  Find out what N will trigger collision-counting countermeasures. >> (2)  Insert N-1 colliding

[issue13703] Hash collision security issue

Marc-Andre Lemburg added the comment: Jim Jewett wrote: > > Jim Jewett added the comment: > > On Mon, Feb 6, 2012 at 8:12 AM, Marc-Andre Lemburg > wrote: >> >> Marc-Andre Lemburg added the comment: >> >> Antoine Pitrou wrote: >>> >>> The simple collision counting approach leaves a gaping ho

[issue13703] Hash collision security issue

Jim Jewett added the comment: On Mon, Feb 6, 2012 at 8:12 AM, Marc-Andre Lemburg wrote: > > Marc-Andre Lemburg added the comment: > > Antoine Pitrou wrote: >> >> The simple collision counting approach leaves a gaping hole open, as >> demonstrated by Frank. > Could you elaborate on this ? > N

[issue13703] Hash collision security issue

Marc-Andre Lemburg added the comment: Antoine Pitrou wrote: > > The simple collision counting approach leaves a gaping hole open, as > demonstrated by Frank. Could you elaborate on this ? Note that I've updated the collision counting patch to cover both possible attack cases I mentioned in h

[issue13703] Hash collision security issue

Antoine Pitrou added the comment: > It is an issue. Not only in terms of startup time, but also > because randomization per default makes Python behave in > non-deterministc ways - which is not what you want from a > programming language or interpreter (unless you explicitly > tell it to behave

[issue13703] Hash collision security issue

Marc-Andre Lemburg added the comment: STINNER Victor wrote: > > STINNER Victor added the comment: > >> In a security fix release, we shouldn't change the linkage procedures, >> so I recommend that the LoadLibrary dance remains. > > So the overhead in startup time is not an issue? It is an i

[issue13703] Hash collision security issue

STINNER Victor added the comment: > In a security fix release, we shouldn't change the linkage procedures, > so I recommend that the LoadLibrary dance remains. So the overhead in startup time is not an issue? -- ___ Python tracker

[issue13703] Hash collision security issue

Martin v. Löwis added the comment: IIUC, Win9x and NT4 are not supported anymore in any of the target releases of the patch, so calling CryptGenRandom should be fine. In a security fix release, we shouldn't change the linkage procedures, so I recommend that the LoadLibrary dance remains. ---

[issue13703] Hash collision security issue

STINNER Victor added the comment: It looks like it was not yet decided if the CryptoGen API or a weak LCG should be used on Windows. Extract of add-randomization-to-3.1-dmalcolm-2012-02-01-001.patch: +#ifdef MS_WINDOWS +#if 1 +(void)win32_urandom((unsigned char *)secret, secret_size,

[issue13703] Hash collision security issue

Dave Malcolm added the comment: Am attaching a backport of optin-hash-randomization-for-3.1-dmalcolm-2012-01-30-002.patch to 2.6 Randomization covers the str, unicode and buffer types; equality of hashes is preserved for these types. -- Added file: http://bugs.python.org/file24375/o

[issue13703] Hash collision security issue

Martin added the comment: > Has anyone had a chance to try this patch on Windows? Martin? I'm > hoping that it doesn't impose a startup cost in the default > no-randomization cost, and that any startup cost in the -R case is > acceptable. Just tested as requested. Is the patch against 3.1 for

[issue13703] Hash collision security issue

Dave Malcolm added the comment: I slightly messed up the test_hash.py changes. Revised patch attached: optin-hash-randomization-for-3.1-dmalcolm-2012-01-30-002.patch -- Added file: http://bugs.python.org/file24371/optin-hash-randomization-for-3.1-dmalcolm-2012-01-30-002.patch _

[issue13703] Hash collision security issue

Jim Jewett added the comment: On Mon, Jan 30, 2012 at 12:31 PM, Dave Malcolm added the comment: > It's useful for the selftests, so I've kept PYTHONHASHSEED. The reason to read PYTHONHASHSEED was so that multiple members of a cluster could use the same hash. It would have been nice to have

[issue13703] Hash collision security issue

Dave Malcolm added the comment: It's useful for the selftests, so I've kept PYTHONHASHSEED. However, I've removed it from the man page; the only other place it's mentioned (in Doc/using/cmdline.rst) I now explicitly say that it exists just to serve the interpreter's own selftests. Am attaching

[issue13703] Hash collision security issue

Martin v. Löwis added the comment: > Rather than the "" empty string for off I suggest an explicit string > that makes it clear what the meaning is. PYTHONHASHSEED="disabled" > perhaps. > > Agreed, if we can have a single env var that is preferred. It is more > obvious that the PYTHONHASHSEED

[issue13703] Hash collision security issue

Gregory P. Smith added the comment: > What about PYTHONHASHSEED= -> off, PYTHONHASHSEED=0 -> random, > PYTHONHASHSEED=n -> n ? I agree with Jim that it's better to have one > env. variable than two. Rather than the "" empty string for off I suggest an explicit string that makes it clear what th

[issue13703] Hash collision security issue

Zbyszek Szmek added the comment: What about PYTHONHASHSEED= -> off, PYTHONHASHSEED=0 -> random, PYTHONHASHSEED=n -> n ? I agree with Jim that it's better to have one env. variable than two. -- ___ Python tracker

[issue13703] Hash collision security issue

Dave Malcolm added the comment: On Sat, 2012-01-28 at 23:56 +, Terry J. Reedy wrote: > Terry J. Reedy added the comment: > > > I think you should check with randomization enabled, if only to see the > > nature of the failures and if they are expected. > > Including the list of when-enable

[issue13703] Hash collision security issue

Dave Malcolm added the comment: On Sun, 2012-01-29 at 00:06 +, Dave Malcolm wrote: I went ahead and added the flag to sys.flags, so now $ make test TESTPYTHONOPTS=-R shows: Testing with flags: sys.flags(debug=0, division_warning=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode

[issue13703] Hash collision security issue

Martin v. Löwis added the comment: > Given PYTHONHASHSEED, what is the point of PYTHONHASHRANDOMIZATION? How would you do what it does without it? I.e. how would you indicate that it should randomize the seed, rather than fixing the seed value? > On startup, python reads a config file with the

[issue13703] Hash collision security issue

Mark Shannon added the comment: Barry A. Warsaw wrote: > Barry A. Warsaw added the comment: > > On Jan 28, 2012, at 07:26 PM, Dave Malcolm wrote: > >> This turns out to pass without PYTHONHASHRANDOMIZATION in the >> environment, and fail intermittently with it. >> >> Note that "make test" inv

[issue13703] Hash collision security issue

Jim Jewett added the comment: Given PYTHONHASHSEED, what is the point of PYTHONHASHRANDOMIZATION? Alternative: On startup, python reads a config file with the seed (which defaults to zero). Add a function to write a random value to that config file for the next startup. -- _

[issue13703] Hash collision security issue

Barry A. Warsaw added the comment: On Jan 28, 2012, at 07:26 PM, Dave Malcolm wrote: >This turns out to pass without PYTHONHASHRANDOMIZATION in the >environment, and fail intermittently with it. > >Note that "make test" invokes the built python with "-E", so that it >ignores the setting of PYTH

[issue13703] Hash collision security issue

Dave Malcolm added the comment: On Sat, 2012-01-28 at 23:56 +, Terry J. Reedy wrote: > Terry J. Reedy added the comment: > > > I think you should check with randomization enabled, if only to see the > > nature of the failures and if they are expected. > > Including the list of when-enable

[issue13703] Hash collision security issue

Terry J. Reedy added the comment: > I think you should check with randomization enabled, if only to see the > nature of the failures and if they are expected. Including the list of when-enabled expected failures in the release notes would help those who compile and test. -- _

[issue13703] Hash collision security issue

Antoine Pitrou added the comment: > Passes "make test" on this x86_64 Fedora 15 box, --with-pydebug, though > that's without randomization enabled (it just does it within individual > test cases that explicitly enable it). I think you should check with randomization enabled, if only to see the

[issue13703] Hash collision security issue

Dave Malcolm added the comment: On Sat, 2012-01-28 at 20:05 +, Benjamin Peterson wrote: > Benjamin Peterson added the comment: > > I think we don't need to mess with tests in 2.6/3.1, but everything should > pass under 2.7 and 3.2. New version of the patch for 3.1 optin-hash-randomizat

[issue13703] Hash collision security issue

Benjamin Peterson added the comment: I think we don't need to mess with tests in 2.6/3.1, but everything should pass under 2.7 and 3.2. -- ___ Python tracker ___ __

  1   2   3   4   >