[Python-Dev] Draft PEP: Maintenance of Python Releases

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On May 14, 2007, at 7:19 PM, Martin v. Löwis wrote:

>> Still, I'm in agreement with you that the repository holds the  
>> security
>> patches and that the tarballs are a convenience.  They are an  
>> important
>> convenience though, so I would say that they should be released in a
>> timely manner after the commit of the security patches.  I don't  
>> think
>> we need to be that exact about spelling out when that happens.
>>
>> (I personally would like to see it within "weeks" of a security  
>> patch,
>> not "months" or "years".)
>
> Couldn't that lead to many more 2.x.y releases in the "security fixes"
> period than in the "active maintenance" period? For active  
> maintenance,
> we don't do roll security fixes into releases more often than every
> six months.
>
> I would dislike a quick succession of 2.3.7, 2.3.8, 2.3.9, etc.
> (also because these numbers should not grow above 10 :-)

I think we could reasonably batch security releases, if we know that  
there are a few critical issues in the pipeline.  That ought to be  
part of the job of the PSRT.  Personally, I don't care much if the  
micro release number goes above 10 although I know there are many  
here who don't like that.  We should definitely try to reduce churn.   
It's a balancing act.

>> Also, I would like to document explicit that it is the  
>> responsibility of
>> the PSRT (or its designate) to commit security patches to revision
>> control.  The act of committing these patches is a public event  
>> and has
>> an important impact on any embargoes agreed upon by the PSRT with  
>> other
>> organizations.
>
> I also disagree. Regular committers should continue to do that. I
> haven't seen a single activity from the PSRT (or, perhaps one), so
> for all I can tell, it doesn't exist.
>
> If a security patch is reported to the Python bug tracker, it's as
> public as it can get.

Right, but hopefully people know to report them to security at python  
dot org instead.  Also hopefully, the new tracker will support  
private/security bug reports that won't be made public (I don't  
actually know if this is the case or not).

> If PSRT members (who are they, anyway) also
> happen to be committers, they can commit these changes at the
> time the PSRT deems appropriate. If they are not committers, they
> need to post the patch to SF as anybody else.
>
> (you can tell that I come from a country where people are quite
> skeptical about the secret service).

There's no secret police here, since almost anyone who's foolish  
enough to volunteer to do some work could easily infiltrate that most  
cloistered of organizations.

I believe there is value in having a PSRT that coordinates security  
reports, fixes, and disclosures.  If the community disagrees, that's  
cool.  But in that case there's not much point in a security at  
python dot org mailing list or a PSRT, so let's disband them.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBRkm9RHEjvBPtnXfVAQKO5gP+IE+AhsUo28ayVojGWbIyupV0eIYBrOke
R+Hvulllcr9LAVmlxlWNZV+TeReavKL+SSzmoyzj/Dv2U5szvTRld7Ca4PBl+mJ8
mfyjqg6uWp1At4OVhf93J6JCrLZkw2sY1lH+yAfcvmxivTr7Rf5+vugDJ822enUt
pKtcowVQCwI=
=ms5P
-----END PGP SIGNATURE-----