Message174989
| 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:03 | christian.heimes | set | recipients:
+ christian.heimes, lemburg, arigo, vstinner, benjamin.peterson, Arfrever, alex, dmalcolm, PaulMcMillan, serhiy.storchaka, Vlado.Boza, koniiiik, camara |
| 2012年11月06日 16:08:03 | christian.heimes | set | messageid: <1352218083.47.0.0151481153495.issue14621@psf.upfronthosting.co.za> |
| 2012年11月06日 16:08:03 | christian.heimes | link | issue14621 messages |
| 2012年11月06日 16:08:02 | christian.heimes | create |
|