On Apr 13, 2012, at 12:01 AM, Max Bowsher wrote: >The reason is because apr 1.4.6 changed its hashtable implementation to >incorporate randomness into the hash function. This was to prevent >possible DoS attacks which are based on feeding a server data which it >will put into a hash, which will cause the hash function to perform >pathologically badly. > >Unfortunately, it's easy to see how this can completely break a >testsuite's comparisons against hardcoded expected values - hence the FTBFS.
The same basic vulnerability affected all stable Python versions. We *just* released the updates for all stable releases in the 2 and 3 series. This also introduces hash randomization, but in the stable releases it is disabled by default, due to buggy applications out there which erroneously rely on predicable iteration order of dicts and sets, in violation of long-term stated Python semantics. (Hash randomization will be enabled by default in Python 3.3). One thing that Python did is to introduce a mechanism to force the hash randomization into predictable and repeatable values, so that applications which aren't affected by the vulnerability (e.g. they do not accept untrusted input) or which need repeatable values for test suites and such, can still succeed. Hashing this out <wink> is one of the reasons why it took so long to get this implemented and released in Python. >I have a workaround, but it's not exactly pretty. The above is mostly just FYI. I don't know if Python's approach makes sense for Subversion, or whether it's too much work to patch upstream in this regard. Cheers, -Barry
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
