This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Unsupported provider

Author christian.heimes
Recipients Arfrever, PaulMcMillan, Vlado.Boza, alex, arigo, benjamin.peterson, camara, christian.heimes, dmalcolm, koniiiik, lemburg, serhiy.storchaka, vstinner
Date 2012-11-06.16:08:02
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1352218083.47.0.0151481153495.issue14621@psf.upfronthosting.co.za>
In-reply-to
Content
I deem hash randomization and collision counting as a poor man's workaround for the actual issue. Perhaps we shouldn't try too hard to fix an unsuitable data type. Hash maps have a known worst case complexity of O(n). A O(log n) algorithm should be used to parses and malicious key/value pairs.

How about Python grows a additional btree implementation in its collections module? I know that it's not going to fix existing code. However in the long run it's the best safeguard against hash collision attacks. I'm thinking about a simple, self balancing btree like red-black-tree. A quick search on Wikipedia also revealed Scapegoat and Splay tree with interesting properties.
History
Date User Action Args
2012-11-06 16:08:03christian.heimessetrecipients: + christian.heimes, lemburg, arigo, vstinner, benjamin.peterson, Arfrever, alex, dmalcolm, PaulMcMillan, serhiy.storchaka, Vlado.Boza, koniiiik, camara
2012-11-06 16:08:03christian.heimessetmessageid: <1352218083.47.0.0151481153495.issue14621@psf.upfronthosting.co.za>
2012-11-06 16:08:03christian.heimeslinkissue14621 messages
2012-11-06 16:08:02christian.heimescreate