More significantly, any security problem is likely to be with a
specific function or object that has been implemented in C.
False; the Cookie module example we talked about was caused by an unforeseen interaction between pure Python modules (Cookie and pickle).
Fair cop on the C thing, but that example otherwise illustrates my point perfectly.
Unpickling untrusted data is just as dangerous as evaluating or executing untrusted data.
This is *still* dangerous, because there *is no patch* to fix the problem. There are only documentation changes to highlight the security risks associated with unpickling, and Deprecation Warnings on the Cookie classes which use this unsafe feature.
So, the only effective mechanism is to get the word out to Python *users* that the feature is unsafe, and should be used with care, which basically requires telling the world about the problem.
Any time Python has a problem of this sort, there is going to be at least one solution, and only possibly two:
1. Avoid the feature that represents a security risk
2. Eliminate the security risk in a maintenance update.
The first solution applies regardless of whether the security risk is inherent in Python's design or not. Some obvious examples (given above) relate to execution of untrusted code.
The second solution applies only to bugs in the CPython implementation and extension modules. And often, tweaking the application's Python code to avoid the dangerous features is going to be faster (and safer) than changing over to a new Python version.
By keeping the process public, and clearly identifying the problematic features, application developers can immediately start working on protecting themselves, in parallel with the CPython developers (possibly) working on a new maintenance release.
To go with the 72 hours + 8 example you gave - what if you could work around the broken feature in 6?
I suspect we'll have to agree to disagree on this point. Where we can agree is that I certainly wouldn't be unhappy if SF had a feature like Bugzilla's security flag.
Regards, Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list
