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.
Regards,
Nick.
--
Nick Coghlan | ncoghlan at email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
More information about the Python-list
mailing list