Who should security issues be reported to?

[Paul Rubin]

Nick Coghlan <ncoghlan at iinet.net.au> 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.