-----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.