Message152781
On Mon, Feb 6, 2012 at 4:41 PM, Marc-Andre Lemburg
<report@bugs.python.org>wrote:
>
> Marc-Andre Lemburg <mal@egenix.com> added the comment:
>
> Gregory P. Smith wrote:
> >
> > Gregory P. Smith <greg@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 <report@bugs.python.org>
> <http://bugs.python.org/issue13703>
> _______________________________________
>
Can't randomization just be applied to integers as well?
Alex |
|
Date |
User |
Action |
Args |
2012-02-06 21:42:28 | alex | set | recipients:
+ alex, lemburg, gvanrossum, tim.peters, loewis, barry, georg.brandl, terry.reedy, gregory.p.smith, jcea, mark.dickinson, pitrou, vstinner, christian.heimes, benjamin.peterson, eric.araujo, grahamd, Arfrever, v+python, zbysz, skrah, dmalcolm, gz, neologix, Arach, Mark.Shannon, eric.snow, Zhiping.Deng, Huzaifa.Sidhpurwala, Jim.Jewett, PaulMcMillan, fx5, skorgu |
2012-02-06 21:42:27 | alex | link | issue13703 messages |
2012-02-06 21:42:27 | alex | create | |
|