From mark at msapiro.net  Sun Feb 13 22:58:33 2011
From: mark at msapiro.net (Mark Sapiro)
Date: Sun, 13 Feb 2011 13:58:33 -0800
Subject: [Mailman-Developers] Mailman Security Patch Announcement
Message-ID: <4D585409.3080305@msapiro.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

An XXS vulnerability affecting Mailman 2.1.14 and prior versions has
recently been discovered. A patch has been developed to address this
issue. The patch is small, affects only one module and can be applied to
a live installation without requiring a restart.

In order to accommodate those who need some notice before applying such
a patch, the patch will be posted on Friday, 18 February at about 16:00
GMT to the same four lists to which this announcement is addressed.

- -- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFNWFQIVVuXXpU7hpMRAixMAJ9CvXBKvSkkF6JAj9qfnPVOQBOz9QCg/ASx
RKTuYnogMT0S96GqSclcXyY=
=l9sU
-----END PGP SIGNATURE-----

From mark at msapiro.net  Fri Feb 18 17:01:57 2011
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 18 Feb 2011 08:01:57 -0800
Subject: [Mailman-Developers] Mailman Security Patch Announcement
In-Reply-To: <4D585409.3080305@msapiro.net>
References: <4D585409.3080305@msapiro.net>
Message-ID: <4D5E97F5.5060203@msapiro.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/13/2011 1:58 PM, Mark Sapiro wrote:
> An XXS vulnerability affecting Mailman 2.1.14 and prior versions has
> recently been discovered. A patch has been developed to address this
> issue. The patch is small, affects only one module and can be applied to
> a live installation without requiring a restart.
> 
> In order to accommodate those who need some notice before applying such
> a patch, the patch will be posted on Friday, 18 February at about 16:00
> GMT to the same four lists to which this announcement is addressed.


The vulnerability has been assigned CVE-2011-0707.

The patch is attached as confirm_xss.patch.txt.

- -- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFNXpf1VVuXXpU7hpMRAs1nAJ97r3VEu5b5jl4JhdNv3r6x+ElqjQCghU+w
Gp0hqWatECAYyAIL7IH9dGk=
=8U6M
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: confirm_xss.patch.txt
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20110218/15500b22/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: confirm_xss.patch.txt.sig
Type: application/octet-stream
Size: 65 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20110218/15500b22/attachment.obj>

From dave at aasv.org  Fri Feb 18 20:13:38 2011
From: dave at aasv.org (David Brown)
Date: Fri, 18 Feb 2011 14:13:38 -0500
Subject: [Mailman-Developers] Mailman Security Patch Announcement
Message-ID: <004e01cbcf9f$f26c3ac0$d744b040$@aasv.org>

Sorry for the n00b moment, but am I correct to think that the way to apply
the patch is to issue the command:

patch <pathTo_Mailman/cgi/confirm.py> <pathTo_confirm_xss.patch.txt>

...when logged in with appropriate permissions and where each
<thingInBrackets> is replaced with the appropriate file path.

(I did check to see whether there were instructions posted on the web page.
Maybe you included them on a different list.)

Thanks,
Dave
--
David Brown
dave at aasv.org ; webmaster at aasv.org


-----Original Message-----
From: mailman-developers-bounces+dave=aasv.org at python.org
[mailto:mailman-developers-bounces+dave=aasv.org at python.org] On Behalf Of
Mark Sapiro
Sent: Friday, February 18, 2011 11:02 AM
To: Mailman Announce; Mailman i18n; Mailman Users; Mailman Developers
Subject: Re: [Mailman-Developers] Mailman Security Patch Announcement

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/13/2011 1:58 PM, Mark Sapiro wrote:
> An XXS vulnerability affecting Mailman 2.1.14 and prior versions has 
> recently been discovered. A patch has been developed to address this 
> issue. The patch is small, affects only one module and can be applied 
> to a live installation without requiring a restart.
> 
> In order to accommodate those who need some notice before applying 
> such a patch, the patch will be posted on Friday, 18 February at about 
> 16:00 GMT to the same four lists to which this announcement is addressed.


The vulnerability has been assigned CVE-2011-0707.

The patch is attached as confirm_xss.patch.txt.

- -- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFNXpf1VVuXXpU7hpMRAs1nAJ97r3VEu5b5jl4JhdNv3r6x+ElqjQCghU+w
Gp0hqWatECAYyAIL7IH9dGk=
=8U6M
-----END PGP SIGNATURE-----


From mark at msapiro.net  Fri Feb 18 22:06:28 2011
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 18 Feb 2011 13:06:28 -0800
Subject: [Mailman-Developers] Mailman Security Patch Announcement
In-Reply-To: <004e01cbcf9f$f26c3ac0$d744b040$@aasv.org>
Message-ID: <PC1952011021813062807500c15464a@MSAPIRO>

David Brown wrote:

>Sorry for the n00b moment, but am I correct to think that the way to apply
>the patch is to issue the command:
>
>patch <pathTo_Mailman/cgi/confirm.py> <pathTo_confirm_xss.patch.txt>
>
>...when logged in with appropriate permissions and where each
><thingInBrackets> is replaced with the appropriate file path.


That will work in this case because the patch changes only the one
file. In general, the preferred method is

cd $prefix
patch -p0 < path_to_patch_file

where $prefix is the directory that contains the Mailman/ directory. In
a default source install, this is /usr/local/mailman/ - YMMV.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From jimpop at gmail.com  Fri Feb 18 22:28:55 2011
From: jimpop at gmail.com (Jim Popovitch)
Date: Fri, 18 Feb 2011 16:28:55 -0500
Subject: [Mailman-Developers] [Mailman-Announce] Mailman Security Patch
	Announcement
In-Reply-To: <4D5E97F5.5060203@msapiro.net>
References: <4D585409.3080305@msapiro.net>
	<4D5E97F5.5060203@msapiro.net>
Message-ID: <AANLkTimyw5ZAL-u+frAhMmxK94jYpyzf0zoLZabW7KzQ@mail.gmail.com>

On Fri, Feb 18, 2011 at 11:01, Mark Sapiro <mark at msapiro.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2/13/2011 1:58 PM, Mark Sapiro wrote:
>> An XXS vulnerability affecting Mailman 2.1.14 and prior versions has
>> recently been discovered. A patch has been developed to address this
>> issue. The patch is small, affects only one module and can be applied to
>> a live installation without requiring a restart.
>>
>> In order to accommodate those who need some notice before applying such
>> a patch, the patch will be posted on Friday, 18 February at about 16:00
>> GMT to the same four lists to which this announcement is addressed.
>
>
> The vulnerability has been assigned CVE-2011-0707.
>
> The patch is attached as confirm_xss.patch.txt.

Mark, I want to say Thank You for the advanced notification and the
patch.  Mailman continues to be the leading substantive communication
enabler, and it is entirely due to the dedication and quality work of
yourself and the Mailman developer community.

Thank you,

-Jim P.

From stephen at xemacs.org  Sat Feb 19 08:07:13 2011
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 19 Feb 2011 16:07:13 +0900
Subject: [Mailman-Developers] Mailman Security Patch Announcement
In-Reply-To: <4D5E97F5.5060203@msapiro.net>
References: <4D585409.3080305@msapiro.net>
	<4D5E97F5.5060203@msapiro.net>
Message-ID: <878vxcpkny.fsf@uwakimon.sk.tsukuba.ac.jp>

Restricting to "developers".

I wonder if hunks like

 > @@ -471,7 +471,7 @@
 >      if fullname is None:
 >          fullname = _('<em>Not available</em>')
 >      else:
 > -        fullname = Utils.uncanonstr(fullname, lang)
 > +        fullname = Utils.websafe(Utils.uncanonstr(fullname, lang))
 >      table.AddRow([_("""Your confirmation is required in order to complete the
 >      unsubscription request from the mailing list <em>%(listname)s</em>.  You
 >      are currently subscribed with

wouldn't better be done in table.AddRow, etc?  Specifically I have in
mind some sort of device where the *default* behavior is "websafe()",
and you have to mark variable text as "safe" to get "active" markup.

I'm pretty sure this is not appropriate for 2.x (too invasive), but
maybe it's an idea for Mailman 3.


From matju at artengine.ca  Sat Feb 19 17:29:04 2011
From: matju at artengine.ca (Mathieu Bouchard)
Date: Sat, 19 Feb 2011 11:29:04 -0500 (EST)
Subject: [Mailman-Developers] Mailman Security Patch Announcement
In-Reply-To: <PC1952011021813062807500c15464a@MSAPIRO>
References: <PC1952011021813062807500c15464a@MSAPIRO>
Message-ID: <alpine.DEB.2.00.1102191128110.573@paik.artengine.ca>

On Fri, 18 Feb 2011, Mark Sapiro wrote:
> David Brown wrote:
>> Sorry for the n00b moment, but am I correct to think that the way to apply
>> the patch is to issue the command:
>> patch <pathTo_Mailman/cgi/confirm.py> <pathTo_confirm_xss.patch.txt>
>> ...when logged in with appropriate permissions and where each
>> <thingInBrackets> is replaced with the appropriate file path.
[...]

will there soon be an actual release of MailMan that includes the fix??

  _______________________________________________________________________
| Mathieu Bouchard ---- t?l: +1.514.383.3801 ---- Villeray, Montr?al, QC

From mark at msapiro.net  Sat Feb 19 19:10:31 2011
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 19 Feb 2011 10:10:31 -0800
Subject: [Mailman-Developers] Mailman Security Patch Announcement
In-Reply-To: <alpine.DEB.2.00.1102191128110.573@paik.artengine.ca>
References: <PC1952011021813062807500c15464a@MSAPIRO>
	<alpine.DEB.2.00.1102191128110.573@paik.artengine.ca>
Message-ID: <dceb357c-90a3-430c-966f-9a60f087ac42@email.android.com>



"Mathieu Bouchard" <matju at artengine.ca> wrote:

>
>will there soon be an actual release of MailMan that includes the fix??


The fix has been committed to the Bazaar branch at lp:mailman/2.1 and will be in the 2.1.15 release. There is no scheduled date yet.

-- 
Mark Sapiro - mark at msapiro.net

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

From msk at cloudmark.com  Fri Feb 25 04:36:31 2011
From: msk at cloudmark.com (Murray S. Kucherawy)
Date: Thu, 24 Feb 2011 19:36:31 -0800
Subject: [Mailman-Developers] mailman and DKIM
Message-ID: <F5833273385BB34F99288B3648C4F06F1341E74488@EXCH-C2.corp.cloudmark.com>

Hi,

I'm authoring a document within the DKIM working group at the IETF to talk about the use of DKIM in the context of mailing lists.  I believe one or more of you is already at least monitoring the working group traffic on that topic, and thanks for that.

Mailing Lists Managers legitimately modify messages sent through them.  (After all, lists are, essentially, re-posting a new message and they can do what they want.) DKIM has a minimal feature that attempts to allow a signature to survive transiting mailing lists, by ignoring text added to the end.

A suggestion has come up that I'd like to bounce off of you. We're interested in doing a better job of surviving the transit.  That means that DKIM would have to adjust to other modifications made by MLMs, such as altering Subject: field contents.

What a few of us would like to explore is the idea of collaborating with the MLM community to develop a profile for MLM message modifications that DKIM can be enhanced to survive.  For example, a new canonicalization algorithm might tolerate the addition of a "[...]" string at the beginning of a Subject line.  We would document this profile and MLM implementers can choose to support it.

This would be a voluntary and cooperative effort.  DKIM signers would have one more configuration choice.  MLM operators would have a special kind of profile that could apply to a list.  Or not.

Our initial discussions have come up with a few idea.  No doubt some are unworkable, but they should at least serve to get further discussion going:

1) add a way to DKIM to have small Subject: modifications be tolerated; something like "exclude from the signed portion any leading text in the Subject: field that is contained within square brackets and includes only letters, numbers, hyphens and underscores, to a maximum of 32 characters", which would allow MLMs to add a short token such as the list name for use by receivers in mailbox sorting but would make it tough for abusers to put a URI there;

2) encourage people to sign with "l=" tags, but recommend that receivers enforce a policy that says any appended text must be no more than a couple of lines long and contain no URLs, or some other similar restriction;

3) explore ways to increase use and utility of the List-* header fields.

I'd like to hear your views on such an approach and any other suggestions you may have.  As a representative of The OpenDKIM Project, which is used by AOL and Yahoo to perform DKIM verifications, I can say we're in a position to conduct some real experiments and get the code out to a wide distribution if we come up with something that has the potential to be successful.

Let me know what you think.

Cheers,
-MSK



From iane at sussex.ac.uk  Fri Feb 25 15:08:47 2011
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Fri, 25 Feb 2011 14:08:47 +0000
Subject: [Mailman-Developers] mailman and DKIM
In-Reply-To: <F5833273385BB34F99288B3648C4F06F1341E74488@EXCH-C2.corp.cloudmark.com>
References: <F5833273385BB34F99288B3648C4F06F1341E74488@EXCH-C2.corp.cloudmark.com>
Message-ID: <FF34CE0AAFF58B3E110A6F2B@lewes.staff.uscs.susx.ac.uk>



--On 24 February 2011 19:36:31 -0800 "Murray S. Kucherawy" 
<msk at cloudmark.com> wrote:

> Hi,
>
> I'm authoring a document within the DKIM working group at the IETF to
> talk about the use of DKIM in the context of mailing lists.  I believe
> one or more of you is already at least monitoring the working group
> traffic on that topic, and thanks for that.
>
> Mailing Lists Managers legitimately modify messages sent through them.
> (After all, lists are, essentially, re-posting a new message and they can
> do what they want.) DKIM has a minimal feature that attempts to allow a
> signature to survive transiting mailing lists, by ignoring text added to
> the end.
>
> A suggestion has come up that I'd like to bounce off of you. We're
> interested in doing a better job of surviving the transit.  That means
> that DKIM would have to adjust to other modifications made by MLMs, such
> as altering Subject: field contents.

I think this is only valuable for users of ADSP. Other people would expect 
their signatures to break, and be supplemented with a good signature 
generated by the list server.


> What a few of us would like to explore is the idea of collaborating with
> the MLM community to develop a profile for MLM message modifications that
> DKIM can be enhanced to survive.  For example, a new canonicalization
> algorithm might tolerate the addition of a "[...]" string at the
> beginning of a Subject line.  We would document this profile and MLM
> implementers can choose to support it.
>
> This would be a voluntary and cooperative effort.  DKIM signers would
> have one more configuration choice.  MLM operators would have a special
> kind of profile that could apply to a list.  Or not.
>
> Our initial discussions have come up with a few idea.  No doubt some are
> unworkable, but they should at least serve to get further discussion
> going:
>
> 1) add a way to DKIM to have small Subject: modifications be tolerated;
> something like "exclude from the signed portion any leading text in the
> Subject: field that is contained within square brackets and includes only
> letters, numbers, hyphens and underscores, to a maximum of 32
> characters", which would allow MLMs to add a short token such as the list
> name for use by receivers in mailbox sorting but would make it tough for
> abusers to put a URI there;

Perhaps you could modify the syntax of the h= tag, to allow, say 
[12]+subject+[5] to mean that 12 unknown characters may prefix the signed 
header, and 5 may follow, provided they are bracketed. I'd suggest only 
permitting bracketed additions, so perhaps this could be expressed as 
12+subject+5 instead. I suppose all of this might break existing 
implementations, so perhaps a separate tag would be required.

> 2) encourage people to sign with "l=" tags, but recommend that receivers
> enforce a policy that says any appended text must be no more than a
> couple of lines long and contain no URLs, or some other similar
> restriction;

Maybe the l= syntax could be extended. Eg, l=12544+512 would mean "I'm 
signing 12544 octets, and permitting the addition of a further 512

>
> 3) explore ways to increase use and utility of the List-* header fields.

Well, if the sender knows that the list is going to add a List-ID header, 
then it could add that before signing. I doubt this would scale well, 
though.

> I'd like to hear your views on such an approach and any other suggestions
> you may have.  As a representative of The OpenDKIM Project, which is used
> by AOL and Yahoo to perform DKIM verifications, I can say we're in a
> position to conduct some real experiments and get the code out to a wide
> distribution if we come up with something that has the potential to be
> successful.
>
> Let me know what you think.
>
> Cheers,
> -MSK
>
>
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives:
> http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe:
> http://mail.python.org/mailman/options/mailman-developers/iane%40sussex.a
> c.uk
>
> Security Policy: http://wiki.list.org/x/QIA9



-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/



From mark at msapiro.net  Fri Feb 25 19:42:06 2011
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 25 Feb 2011 10:42:06 -0800
Subject: [Mailman-Developers] mailman and DKIM
In-Reply-To: <F5833273385BB34F99288B3648C4F06F1341E74488@EXCH-C2.corp.cloudmark.com>
Message-ID: <PC1952011022510420606569d715d16@MSAPIRO>

Murray S. Kucherawy wrote:
>
>1) add a way to DKIM to have small Subject: modifications be tolerated; something like "exclude from the signed portion any leading text in the Subject: field that is contained within square brackets and includes only letters, numbers, hyphens and underscores, to a maximum of 32 characters", which would allow MLMs to add a short token such as the list name for use by receivers in mailbox sorting but would make it tough for abusers to put a URI there;


Some MLMs will add a subject prefix other than at the beginning or will
move an existing prefix. E.g.

Subject: Re: Something

becomes

Subject: Re: [List] Something

or

Subject: Re: [List] Something

becomes

Subject: [List] Re: Something

Mailman will do the former if mm_cfg.OLD_STYLE_PREFIXING is True and
will do the latter if mm_cfg.OLD_STYLE_PREFIXING is False.


>2) encourage people to sign with "l=" tags, but recommend that receivers enforce a policy that says any appended text must be no more than a couple of lines long and contain no URLs, or some other similar restriction;


Many lists add short message footers that contain URLs such as a list
information or an unsubscribe link.


>3) explore ways to increase use and utility of the List-* header fields.
>
>I'd like to hear your views on such an approach and any other suggestions you may have.  As a representative of The OpenDKIM Project, which is used by AOL and Yahoo to perform DKIM verifications, I can say we're in a position to conduct some real experiments and get the code out to a wide distribution if we come up with something that has the potential to be successful.


I think there is a good possibility for simple plain text only messages
to pass through an MLM without breaking signatures, however, if the
original message is more complex and the list filters content, e.g.
say a multipart/alternative message has its text/html alternative
removed and the message collapsed to a text/plain message containing
only the text/plain alternative, I don't see a way for signatures to
surve such a transformation.

Since many MUAs compose multipart/alternative messages by default
without the users necessarily even being aware of it, and many lists
transform such messages into simple text/plain messages, I think this
will always be an issue.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan