Message 151754 - Python tracker (original) (raw)

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.