Quoting the announcement [1]: "I am happy to announce the second beta release of Mailman 2.1.10. For technical reasons, there was no 'b2' release. This is a security and bug fix release and it is highly recommended that all sites upgrade to this version. Mailman 2.1.10 also adds support for two new language translations, Hebrew and Slovak and a few new features. [...] ~ Security ~ - The 2.1.9 fixes for CVE-2006-3636 have been enhanced. In particular, ~ many potential cross-site scripting attacks have are now detected in ~ editing templates and updating the list's info attribute via the web ~ admin interface. Thanks again to Moritz Naumann for assistance with ~ this." Note that while speaking of 2.1.10b1 in the initial announcement the new released version is 2.1.10b3 according to [2]. [1] http://mail.python.org/pipermail/mailman-announce/2008-February/000095.html [2] http://mail.python.org/pipermail/mailman-announce/2008-February/000096.html
CVE-2008-0564 has been allocated for these issues.
Created attachment 142699 [details, diff] mailman-2.1.9-fix-XSS.patch Oh, also, if $MAINTAINER doesn't want to update to a beta release (I wouldn't), I'm attaching a patch which was given to me by upstream to fix the issue.
Added -r3. Archs, please go ahead. Note that this introduces the "reworked" mailman-ebuild, which installs into fhs-compliant locations and can be configured much better.
* An example Mailman configuration file for Apache has been installed into: * /50_mailman.conf There's missing ${APACHE_MODULES_CONFDIR} variable (missing eclass?) x86 stable
Arches, please test and mark stable: =net-mail/mailman-2.1.9-r3 Target keywords : "amd64 ppc release sparc x86"
sorry, removing x86 again.
amd64 done
sparc stable
ppc stable plus re-adding amd64.
Seems I've stabilized amd64 in my local cvs tree without committing... Now done. Security, please go ahead with glsa.
This one is ready for GLSA vote. I tend to vote NO.
voting NO, and I close even if we don't have 2 full NO votes since it's XSS. feel free to reopen if you disagree.
Erh? Yes, it's an XSS and thus it can be used to steal accounts, which is a major issue. Why shouldn't this cause a GLSA?? Vote YES (if my opinion as the package maintainer counts) and volunteer to write the glsa if neccessary.
Is it a persistent or non-persistent XSS? Non-persistent issues usually do not get GLSA'd.
Fixed in release snapshot.