Semi-closing a hole

Posted Apr 12, 2012 9:11 UTC (Thu) by intgr (subscriber, #39733)
In reply to: Semi-closing a hole by man_ls
Parent article: Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3 security release

> Closing a security hole and making the fix optional (and not enabled by default) seems like a weird decision

It *WILL* be the default in newer Python versions. Their decision makes very much sense: breaking existing applications in a security release is a no-no, since security updates in general need to be applied quickly -- without requiring all downstreams do a full new QA cycle.

If you start releasing security fixes that break applications by default, then distros will refuse to ship your security fixes and administrators will refuse to apply security fixes to their machines -- leading to worse security for everyone.

And let's admit it -- this denial-of-service problem has existed and has been known about for ages in most languages, it hasn't really been a problem in practice. It would be silly to rush it.

to post comments

Semi-closing a hole

Posted Apr 12, 2012 11:56 UTC (Thu) by intgr (subscriber, #39733) [Link] (2 responses)

> It *WILL* be the default in newer Python versions

To be more specific, it will be the default in Python 3.3 and newer -- since it's a feature release, breaking compatibility is allowed.

Semi-closing a hole

Posted Apr 12, 2012 14:20 UTC (Thu) by cortana (subscriber, #24596) [Link] (1 responses)

So, we'll only need to wait 5-10 more years before it trickles down to end-users!

Semi-closing a hole

Posted Apr 12, 2012 14:35 UTC (Thu) by intgr (subscriber, #39733) [Link]

> So, we'll only need to wait 5-10 more years

No problem, we've waited ~20 years for people to fix this bug (hash table collision DoS is a pretty old and well-known problem). We can wait 10 more for the fix to reach users. ;)