[Python-Dev] Releases for recent security vulnerability

[Nick Coghlan]

On Mon, Apr 18, 2011 at 12:03 AM, Jacob Kaplan-Moss <jacob at jacobian.org> wrote:
> Just to fill in a bit of missing detail about our process since the
> doc doesn't perfectly describe what happens:
>
> * Our pre-announce list is *really* short. It consists of release
> managers for various distributions that distribute packaged versions
> of Django -- Ubuntu, RedHat, and the like. Yes it's a bit of
> bookkeeping, but we feel it's really important to our users: not
> everyone installs the Django package *we* put out, so we think it's
> important to coordinate security releases with downstream distributors
> so that users get a fixed version of Django regardless of how they're
> installing Django in the first place.

I'd rather have Red Hat and Canonical reps *on* the
security at python.org list rather than a separate pre-announce list.

> * We don't really halt all development. I don't know why that's in
> there, except maybe that it pre-dates there being more than a
> couple-three committers. The point is just that we treat the security
> issue as our most important issue at the moment and fix it as quickly
> as possible.

That makes a lot more sense.

> I don't really have a point here as it pertains to python-dev, but I
> thought it's important to clarify what Django *actually* does if it's
> being discussed as a model.

I'd personally like to see a couple of adjustments to
http://www.python.org/news/security/:

1. Identify a specific point-of-contact for the security list, for
security-related questions that aren't actually security issues (e.g.
how would a core developer go about asking to join the PSRT?)
2. Specifically state on the security page where vulnerabilities and
fixes will be announced and the information those announcements will
contain (as a reference for the PSRT when responding to an issue, and
also to inform others of the expected procedure)

The current page does a decent job of describing how to report a
security issue, but doesn't describe anything beyond that.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia