Bugzilla Bug 208710

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 an attachment (id=142699) [details]
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.