BTW, the *real* problem here is that we *really* need to free up Mark for doing more development. Whether he likes it or not. ;-)
Jim Popovitch writes: > On Tue, Apr 15, 2008 at 11:56 AM, Mark Sapiro <[EMAIL PROTECTED]> wrote: > > > > There are two security issues mentioned in the announcement. > > <harsh criticism> > How much sense does it make to announce security issues in a release > CANDIDATE? Come on guys, release a STABLE version (or FIX), then > announce. <--- Standard Operation Procedures. > </harsh criticism> > > Quit feeding the enemy instead of your supporters. That last was *quite* uncalled-for. First of all, there is no such thing as a STABLE security release (you can't beta test it before announcing and you don't have time to alpha test properly), so it can't possibly be S.O.P. Second, the fact that you emphasize STABLE indicates (and you confirm) that you're thinking of a situation where you can't upgrade to an unstable version because of "rules". That's not Mark's problem, that's *your* problem if you are not trusted to judge whether a fix is sufficiently important and stable to be applied. I understand your frustration, but it ain't Mark's fault. Third, you have real problems anyway. Mailman has known security bugs that are not going to get fixed soon (specifically the LIST-request backscatter problem).[1] You are aware of that, right? In the great scheme of things, I don't think the two minor issues fixed in this RC are a really big deal.... Anyway, whether you like it or not, the backscatter issue shows that the Mailman project currently does not put #1 priority on things just because they're labeled "security issues". If you want that changed, it would help to have a better idea of what exactly is most important, because resources aren't infinite. Now, your desire for a stable security release suggests that what you want is a procedure like (0) [EMAIL PROTECTED] receives a report. (1) The security cabal prepares a fix to the current stable release (if necessary, cutting a new branch) and tests it as well as possible. (2) The release is cut as version STABLE.SECURITY-PATCH-NUMBER. (3) The release is announced, and (optionally) a patch published for the DIY crowd. (4) The developers consider whether to forward port or design a different fix for in-development versions (including the next stable/bugfix release). Is that right? If so, how much are you (and others) willing to contribute toward achieving that process? Eg, maybe you could beat Mark to the punch on a few of the routine questions that he must spend 5 hours a week on, or so? Or if you have Python skills, you could volunteer to burn some midnight oil on generating patches and alpha testing? Etc, etc. Footnotes: [1] True, with some effort you can shut those aliases off, but that will invalidate many of the information web pages, and for that reason the secure configuration has not been made default, and probably that will be postponed to Mailman 2.2. ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp