Hi, how about
Option d: Host based salt + Easy-ish to implement – how about basing it on the hostname for example? + transparent for all processes on the same host - probably unit test breakage In fact, we could use host based as default with the option to specify own which would solve the sync problems. That said, I agree with Armin that fixing this in the frameworks isn't an option. Regards, Hynek Am Donnerstag, 29. Dezember 2011 um 13:57 schrieb Armin Ronacher: > Hi, > > Something I should add to this now that I thought about it a bit more: > > Assuming this should be fixed on a language level the solution would > probably be to salt hashes. The most common hash to salt here is the > PyUnicode hash for obvious reasons. > > - Option a: Compiled in Salt > + Easy to implement > - Breaks unittests most likely (those were broken in the first place > but that's still a very annoying change to make) > - Might cause problems with interoperability of Pythons compiled with > different hash salts > - You're not really solving the problem because each linux > distribution (besides Gentoo I guess) would have just one salt > compiled in and that would be popular enough to have the same > issue. > > - Option b: Environment variable for the salt > + Easy-ish to implement > + Easy to synchronize over different machines > - initialization for base types happens early and unpredictive which > makes it hard for embedded Python interpreters (think mod_wsgi and > other things) to specify the salt > > - Option c: Random salt at runtime > + Easy to implement > - impossible to synchronize > - breaks unittests in the same way as a compiled in salt would do > > Where to add the salt to? Unicode strings and bytestrings (byte > objects) I guess since those are the most common offenders. Sometimes > tuples are keys of dictionaries but in that case a contributing factor > to the hash is the string in the tuple anyways. > > Also related: since this is a security related issue, would this be > something that goes into Python 2? Does that affect how a fix would > look like? > > > Regards, > Armin > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org (mailto:Python-Dev@python.org) > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/hs%40ox.cx _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
