Nick Coghlan <[EMAIL PROTECTED]> writes: > After my original flippant reply, I've been thinking some more about > this, and whether CPython can really benefit from initial notification > of a security flaw going privately to the developers first. > > And, due to CPython's release model, I really don't think it can. > > Upgrading your Python interpreter (even to a new maintenance branch > release) in a production environment is usually a fairly involved > exercise requiring a significant amount of testing, and the fact of
That's true of any production environment, and yet if there's a serious flaw, you absolutely have to do it. > So, for CPython, the window of vulnerability is driven mainly by the > time to when application developers, system administrators and end > users get around to upgrading, not by the time to when a patched > version is released. No. If you're running a production system you have to stay on top of security patches and install them ASAP. If a vulnerability is bad enough, you have to close down your service until you're done installing the fix. If it takes 72 hours for the developers to make a patch, and 8 hours for you to install the patch once it's announced, then your exposure to attackers who learn of the bug from the announcement is 10 times smaller if the bug and patch are announced simultaneously than if the bug is announced immediately and the patch is released 72 hours later. > 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). > So the most appropriate response to security issues in the CPython > interpreter and standard library is to notify application developers > as to what the issue is, and exactly which features it affects. It helps a lot if when the application developers are notified, a patch is already available, since once there's a lot of notification, the bug is public. > Sending a private notification to the *interpreter* developers does > nothing to assist in this. Um, it lets them get a patch ready before they notify the app developers. > If the problem is significant, then it should also be brought directly > to the attention of python-dev. It's a sure bet that attackers are monitoring python-dev and one should generally assume that they're monitoring the email of any developer for projects with serious security footprints. Notifying python-dev isn't much different than broadcasting the info on "Attack TV". Security bug reports should be made through SSL-encrypted web pages, not unencrypted email. Bugzilla already has this feature. I think it should also be added to Sourceforge, if it's not already there. If it's available in Sourceforge, then Python's Sourceforge project should enable it. Meanwhile, the OP can always open a CERT notification (www.cert.org), though it usually takes a very long time for anything to happen with those. -- http://mail.python.org/mailman/listinfo/python-list
