Bug 217779

Summary:	Mailman version bump - 2.1.10 (rc1 was just announced)
Product:	Gentoo Linux	Reporter:	tanstaafl <tanstaafl>
Component:	[OLD] Server	Assignee:	Hanno Böck <hanno>
Status:	RESOLVED DUPLICATE
Severity:	enhancement	CC:	boss.gentoo, hncaldwell, mmokrejs, net-mail+disabled, svrmarty
Priority:	High
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---

Description tanstaafl@libertytrek.org 2008-04-15 11:08:38 UTC

Requesting an ebuild for the soon to be released 2.1.10.

This release contains some new features that will be very convenient for everyone... the two main ones I'd like to make use of are the new umbrella lists feature, and the ability to specify a list in any of the 'accept_these_nonmembers_*' fields...

rc1 Announcement:
http://mail.python.org/pipermail/mailman-announce/2008-April/000105.html

2.1.10 planned to be released on April 21st (in one week):
http://mail.python.org/pipermail/mailman-announce/2008-April/000102.html

Reproducible: Always

Comment 1 tanstaafl@libertytrek.org 2008-04-21 20:02:32 UTC

2.1.10 was just released...

Pretty please?

Comment 2 Martin Mokrejš 2008-05-09 16:12:54 UTC

Release Name: 2.1.10

Notes:
  Security

    - The 2.1.9 fixes for CVE-2006-3636 were not complete.  In particular,
      some potential cross-site scripting attacks were not detected in
      editing templates and updating the list's info attribute via the web
      admin interface.  This has been assigned CVE-2008-0564 and has been
      fixed.  Thanks again to Moritz Naumann for assistance with this.

    - There is a new mm_cfg.py/Defaults.py variable
      OWNERS_CAN_CHANGE_MEMBER_PASSWORDS which controls whether the list
      owner can change a member's password from the member's options page.
      This defaults to No and should be changed to Yes only if list owners
      are trusted to not change a member's password, log in as the member
      and make global membership changes.

[cut]

Comment 3 Hanno Böck gentoo-dev

2008-07-04 12:55:29 UTC


*** This bug has been marked as a duplicate of bug 208789 ***