Who should security issues be reported to?

Nick Coghlan ncoghlan at iinet.net.au
Fri Jan 28 22:50:38 EST 2005

grahamd at dscpl.com.au wrote:
> Who are the appropriate people to report security problems to
> in respect of a module included with the Python distribution?
> I don't feel it appropriate to be reporting it on general mailing
> lists.

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 the matter is, you're unlikely to 
do so unless there is some feature or bug-fix in a new version that you really 
need. (I'm still using Python 2.2.2 at work - it's entirely adequate for our 
needs, so there's no real pressure to upgrade on the current project. For a new 
project, I'd probably start with 2.4, planning to go to 2.4.1 in a couple of 
months time, but there aren't really any post-2.2 additions to Python that I 
can't handle living without).

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. In that sort 
of environment, even if the developers were to release a new maintenance patch 
within an hour of being notified of the problem, the window of vulnerability is 
still going to be huge (there are still systems out there running Python *1.5*, 
fer cryin' out loud).

More significantly, any security problem is likely to be with a specific 
function or object that has been implemented in C. This means any such security 
problem can be worked around by not using the affected feature, by employing 
appropriate safeguards against abuse, or by substituting a Python equivalent.

This is something which is going to be application dependent, and relies on 
application developers being notified.

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. Sending a private notification to the 
*interpreter* developers does nothing to assist in this.

In accordance with the above, I would suggest that, even for security problems, 
Python's standard Sourceforge bug tracker is the most appropriate place to file 
the problem report.

If the problem is significant, then it should also be brought directly to the 
attention of python-dev. At that point, the decision may be made to make a 
general announcement as to the feature which needs to be avoided or handled 
carefully. This would likely take the form of announcements on the 
www.python.org website, and on comp.lang.python.announce.


Nick Coghlan   |   ncoghlan at email.com   |   Brisbane, Australia

More information about the Python-list mailing list