On Sat, Jan 21, 2012 at 5:42 PM, Gregory P. Smith <report@bugs.python.org>wrote:

>
> Gregory P. Smith <greg@krypto.org> added the comment:
>
> On Sat, Jan 21, 2012 at 2:45 PM, Antoine Pitrou <report@bugs.python.org>
> wrote:
> >
> > Antoine Pitrou <pitrou@free.fr> added the comment:
> >
> >> You said above that it should be hardcoded; if so, how can it be changed
> >> at run-time from an environment variable?  Or am I misunderstanding.
> >
> > You're right, I used the wrong word. I meant it should be a constant
> > independently of the dict size. But, indeed, not hard-coded in the
> > source.
> >
> >> > > BTW, presumably if we do it, we should do it for sets as well?
> >> >
> >> > Yeah, and use the same env var / sys function.
> >>
> >> Despite the "DICT" in the title?  OK.
> >
> > Well, dict is the most likely target for these attacks.
> >
>
> While true I wouldn't make that claim as there will be applications
> using a set in a vulnerable manner. I'd prefer to see any such
> environment variable name used to configure this behavior not mention
> DICT or SET but just say HASHTABLE.  That is a much better bikeshed
> color. ;)
>
> I'm still in the hash seed randomization camp but I'm finding it
> interesting all of the creative ways others are trying to "solve" this
> problem in a way that could be enabled by default in stable versions
> regardless. :)
>
> -gps
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue13703>
> _______________________________________
>

I'm a little slow, so bear with me, but David, does this counting scheme in
any way address the issue of:

I'm able to put N pieces of data into the database on successive requests,
but then *rendering* that data puts it in a dictionary, which renders that
page unviewable by anyone.