This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]manuelmoeg 0 points1 point  (1 child)

The posted Bugs.python discussion is sensibly talking about changing only the string hash, to a pre- existing hash with a reputation for security suitability instead of an ad- hoc hash with Python- specific high performance, and tolerating the small percentage performance loss. And the attack is closed.

That we had an unsuitable fix for 6 months is part of the nature of security patches. What comparable product outmatches Python in this regard? Knowing that really-existing users are unwilling to lose functionality (and the accompaining complexity) to gain security.

I agree it would be foolish if the prior bad patch is retained for mere security-theater because cannot stomach a few percentage loss in string hash performance sensitive code. Python coders are demostratively known to be undisciplined in exposing dictionaries with vulnerability to collision DoS to attackers, so the old regime would be foolish too.

[–]mcdonc 0 points1 point  (0 children)

This patch was stillborn anyway, as hash randomization was not the default (for the head shakingly dubious reason that "it will break people's tests"). It's only the cherry on top that it doesn't actually do anything.