Alex Gaynor <alex.gay...@gmail.com> added the comment: On Mon, Feb 6, 2012 at 4:41 PM, Marc-Andre Lemburg <rep...@bugs.python.org>wrote:
> > Marc-Andre Lemburg <m...@egenix.com> added the comment: > > Gregory P. Smith wrote: > > > > Gregory P. Smith <g...@krypto.org> 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 problem while being fairly > >>>> straightforward such that we're comfortable putting it in a stable > >>>> release. > >>>> 2. It will be off by default in stable releases and enabled by an > >>>> envar at runtime. This will prevent code breakage from dictionary > >>>> order changing as well as people depending on the hash stability. > >> > >> 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. collisions caused by 3rd types or numbers. > > > > We won't be back-porting anything more than the hash randomization for > > 2.6/2.7/3.1/3.2 but we are free to do more in 3.3 if someone can > > demonstrate it working well and a need for it. > > > > For me, things like collision counting and tree based collision > > buckets when the types are all the same and known comparable make > > sense but are really sounding like a lot of additional complexity. I'd > > *like* to see active black-box design attack code produced that goes > > after something like a wsgi web app written in Python with hash > > randomization *enabled* to demonstrate the need before we accept > > additional protections like this for 3.3+. > > I posted several examples for the integer collision attack on this > ticket. The current randomization patch does not address this at all, > the collision counting patch does, which is why I think both are > needed. > > Note that my comment was more about the desire to *not* recommend > using random hash seeds per default, but instead advocate using > a random but fixed seed, or at least document that using random > seeds that are set during interpreter startup will cause > problems with repeatability of application runs. > > ---------- > > _______________________________________ > Python tracker <rep...@bugs.python.org> > <http://bugs.python.org/issue13703> > _______________________________________ > Can't randomization just be applied to integers as well? Alex ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13703> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
