[Python-Dev] Releases for recent security vulnerability

Stephen J. Turnbull stephen at xemacs.org
Sun Apr 17 20:32:34 CEST 2011


Gustavo Narea writes:

 > Well, that's a long shot. I doubt the people/organizations affected are
 > all aware.

That's really not Python's responsibility.  That's theirs.  Caveats:
Python should have a single place where security patches are announced
*first*, before developer blogs and the like.  Python's documentation
should make it clear at the most important entry points that the
appropriate place to report possible security issues is
security at python.org, not the tracker.  In particular, the tracker's
top page (the one you get from http://bugs.python.org/) should make
that clear.

Ironically, Brian's blog entry outlines a plausible security policy,
but a quick Google didn't find it elsewhere on site:python.org.  Oops,
a different search did find it -- under News/Security Advisories.

The tracker suggestion submitted as
http://psf.upfronthosting.co.za/roundup/meta/issue393.

 > And I doubt they are all capable of patching their system or
 > getting a patched Python from a trusted party.

Then they shouldn't be running Python in a security context, should
they?  Seriously, if they want somebody else to take care of their
security issues for them, they should pay for it.  As in almost areas
of life, security is at best worth what you pay for it.

 > Three weeks after this security vulnerability was *publicly* reported on
 > bugs.python.org,

Again, that's an issue with the reporter not knowing the policy, not
the policy itself, which is to report to security at python.org,
cf. Brian's post and the Security Advisory page.  The caveats above
apply, though.

 > and two days after it was semi-officially announced,
 > I'm still waiting for security updates for my Ubuntu and Debian systems!

Yeah, well, so much for depending on Ubuntu and Debian.  There are
reasons why people pay for RHEL.

 > I reckon if this had been handled differently (i.e., making new releases
 > and communicating it via the relevant channels [1]), we wouldn't have
 > the situation we have right now.

Of course not.  So what?  The question is "what is the best way to
reduce risks?"  *It is not possible to reduce all risks
simultaneously.*  What you are saying is "please keep things obscure
until I'm up to date."

It seems to be a consensus in the security community that most
security holes *are* sufficiently obscure that announcing the problem
before announcing a fix is likely to increase the likelihood of black
hats finding exploits and successfully executing them more than it
increases the likelihood that (3rd party) white hats will find and
contribute a fix.  So the question is whether to rely on obscurity
after the fix is devised.

Now, once there is a fix, there's always hysteresis in implementation,
as you note with respect to Ubuntu and Debian.  If you don't announce
the fix once available, you are increasing risk to conscientious,
patch-capable admins dramatically compared to the case where you give
them the patch.  I don't see why your Ubuntu/Debian systems should
take precedence over systems of those who prefer to rely on self-
built-and-maintained systems.  (In fact, since I generally fall into
the latter category, may I suggest it should be the other way around?
<wink />)

 > May I suggest that you adopt a policy for handling security issues like
 > Django's?
 > http://docs.djangoproject.com/en/1.3/internals/contributing/#reporting-security-issues

I'm -1 on that, except to the extent that it corresponds to existing
policy.  Eg,

    This will probably mean a new release of Django, but in some cases
    it may simply be patches against current releases.

seems to apply to the current case.  I really don't think the policy
Django claims is appropriate for Python for the following reasons,
among others:

    Halt all other development as long as is needed to develop a fix,
    including patches against the current and two previous releases.

is nonsense.  Perhaps what this means is that the "long-time, highly
trusted Django developers" on the security at django list *volunteer* to
put other Django work aside until the security hole is patched.  But
certainly the "hundreds of contributors around the world" won't stop
their work -- they won't know about the moratorium since they're not
on the security list.
In the case of Python, it's not even possible to stop commits without
closing the repo, as not all committers are on the security list.

Even for the security crew, in many cases of security problems, it's
something simple and readily fixed like a buffer overflow or an URL
traversal issue that just needs a simple filter on input before
executing a risky procedure.  So who does the fixing, reviewing, etc
should be decided on a case-by-case basis based on the problem itself
and available expertise IMO.

And this

    Pre-notify everyone we know to be running the affected version(s)
    of Django.

seems positively counter-productive if they're serious about
"everyone".  Surely the black hats are running the affected versions
of Django to test their exploits!  So they get to find out they're
running out of time to execute while the people running affected
versions remain vulnerable until the release.



More information about the Python-Dev mailing list