-----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----- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
