Hello.
I'm the mailman maintainer for mandriva Linux. I'm currently upgrading 2.1.8 to 2.1.9rc1, due to the recent security fixes therein.
I'd like to use this occasion to drop a maximum of patches we still have: patch to its authors ?
- is 2.1.9 still vulnearble to CVE-2005-3573 ? I didn't found any reference to it in the release notes, and the patch [1] still apply
- the default build procedure is not suited to package building: it check target directory directly (which doesn't exist), and leave reference to package build root in python bytecode files. The patches [2] and [3] fixes those issues, maybe they could get integrated.
- we have a patch for the embeded email module that just fix an encoding name [4]. I didn't found reference to a website or a standalone distribution of this module elsewhere. Could you please transmit the
[1] CVE-2005-3573 fix: http://cvs.mandriva.com/cgi-bin/viewvc.cgi/SPECS/mailman/mailman-2.1.6-CVE-2... [2] buildroot references in bytecode fix: http://cvs.mandriva.com/cgi-bin/viewvc.cgi/SPECS/mailman/mailman-2.1.6-CVE-2... [3] buildroot check fix: http://cvs.mandriva.com/cgi-bin/viewvc.cgi/SPECS/mailman/mailman-buildroot-c...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sep 9, 2006, at 10:09 AM, Guillaume Rousse wrote:
I'd like to use this occasion to drop a maximum of patches we still
have:
- is 2.1.9 still vulnearble to CVE-2005-3573 ? I didn't found any reference to it in the release notes, and the patch [1] still apply
This is the first I've seen of this CVE, but it sounds like bugs that
have been addressed in the email package.
- the default build procedure is not suited to package building: it check target directory directly (which doesn't exist), and leave reference to package build root in python bytecode files. The patches [2] and [3] fixes those issues, maybe they could get integrated.
I don't think your links are correct. Link [1] is the same as link [2].
- we have a patch for the embeded email module that just fix an
encoding name [4]. I didn't found reference to a website or a standalone distribution of this module elsewhere. Could you please transmit the patch to its authors ?
There's no [4] link so I don't understand what this one tries to
fix. The email package is developed at the email-sig: <http://
www.python.org/sigs/email>. You should probably post the issue over
there on that sig.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRQYSqnEjvBPtnXfVAQLJpgP/SMowdWbnpicbK9rqeisSIKMffjHP6B1v 6xvFsR3IRmfSin6wIQSMe2yjsVv2Bb7o+tK4u4ts5RE+F0XmBuSu+yeVzq0858y+ dX5iSZHK6b5nrajpR0JFjNTDnir2KPHGr1XlY3vQUhaISeC5wnvWqIiW9KKLat9+ m4F22T7Aqdk= =mzRh -----END PGP SIGNATURE-----
Hi,
Sorry that I was unable to respond.
Barry Warsaw wrote:
On Sep 9, 2006, at 10:09 AM, Guillaume Rousse wrote:
I'd like to use this occasion to drop a maximum of patches we still
have:
- is 2.1.9 still vulnearble to CVE-2005-3573 ? I didn't found any reference to it in the release notes, and the patch [1] still apply
This is the first I've seen of this CVE, but it sounds like bugs that
have been addressed in the email package.
This is mentioned in the NEWS of version 2.1.7.
- A note on CVE-2005-3573: Although the RFC2231 bug example in the CVE has been solved in Mailman 2.1.6, there may be more cases where ToDigest.send_digests() can block regular delivery. We put the send_digests() calling part in a try/except clause and leave a message in the error log if something happened in send_digests(). Daily call of cron/senddigests will provide more detail to the site administrator.
Therefore, 2.1.9 is also not vulnerable. CVE-2005-3573 is a false (delayed) alert.
-- Tokio Kikuchi tkikuchi@is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/
Tokio Kikuchi wrote:
Hi,
Sorry that I was unable to respond.
Barry Warsaw wrote:
On Sep 9, 2006, at 10:09 AM, Guillaume Rousse wrote:
I'd like to use this occasion to drop a maximum of patches we still have:
- is 2.1.9 still vulnearble to CVE-2005-3573 ? I didn't found any reference to it in the release notes, and the patch [1] still apply
This is the first I've seen of this CVE, but it sounds like bugs that have been addressed in the email package.
This is mentioned in the NEWS of version 2.1.7.
- A note on CVE-2005-3573: Although the RFC2231 bug example in the CVE has been solved in Mailman 2.1.6, there may be more cases where ToDigest.send_digests() can block regular delivery. We put the send_digests() calling part in a try/except clause and leave a message in the error log if something happened in send_digests(). Daily call of cron/senddigests will provide more detail to the site administrator.
Therefore, 2.1.9 is also not vulnerable. CVE-2005-3573 is a false (delayed) alert. Thanks, I'll remove it.
Tokio Kikuchi wrote:
ToDigest.send_digests() can block regular delivery. We put the send_digests() calling part in a try/except clause and leave a message in the error log if something happened in send_digests(). Daily call of cron/senddigests will provide more detail to the site administrator.
I noticed this may lead to yet another DoS for digest delivery. The malicious (non-compliant MIME) message may cause other digest deliveries to stop as long as the malicious message remains in the digest.mbox file. I created a patch for this situation and uploaded in the patch area of SF: http://sourceforge.net/tracker/index.php?func=detail&aid=1556858&group_id=103&atid=300103
I think I will commit in the Release-2.1-maint branch and include in the 2.1.9 final release. I appreciate anyone can review the patch.
At this point of writing, I should note 2.1.9(rc1) has no known vulnerablities by which this patch is required.
-- Tokio Kikuchi tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/
On Sep 12, 2006, at 6:38 AM, ???? wrote:
Tokio Kikuchi wrote:
ToDigest.send_digests() can block regular delivery. We put the send_digests() calling part in a try/except clause and leave a
message in the error log if something happened in send_digests().
Daily call of cron/senddigests will provide more detail to the site
administrator.I noticed this may lead to yet another DoS for digest delivery. The malicious (non-compliant MIME) message may cause other digest
deliveries to stop as long as the malicious message remains in the digest.mbox file. I created a patch for this situation and uploaded in the patch area of SF: http://sourceforge.net/tracker/index.php? func=detail&aid=1556858&group_id=103&atid=300103I think I will commit in the Release-2.1-maint branch and include
in the 2.1.9 final release. I appreciate anyone can review the patch.
Let's wait for 2.1.10, because otherwise we're really going to need
another release candidate and another week or so of testing.
-Barry
http://sourceforge.net/tracker/index.php? func=detail&aid=1556858&group_id=103&atid=300103
I think I will commit in the Release-2.1-maint branch and include
in the 2.1.9 final release. I appreciate anyone can review the patch.Let's wait for 2.1.10, because otherwise we're really going to need
another release candidate and another week or so of testing.
Oh, yes. I understand.
-- Tokio Kikuchi, tkikuchi@is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sep 12, 2006, at 7:43 PM, Tokio Kikuchi wrote:
http://sourceforge.net/tracker/index.php?
func=detail&aid=1556858&group_id=103&atid=300103I think I will commit in the Release-2.1-maint branch and
include in the 2.1.9 final release. I appreciate anyone can review the patch. Let's wait for 2.1.10, because otherwise we're really going to
need another release candidate and another week or so of testing.Oh, yes. I understand.
BTW, what do you think about changing the way we hold messages for
digests? E.g. instead of putting them in an mbox file, where it's
more difficult to skip bad messages, stick them in a queue-like
directory and pull them from there. Any messages that can't be read
and scrubbed would just be removed.
Might be too big a change for the 2.1 series, but perhaps we should
look at that for 2.2.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRQ4MG3EjvBPtnXfVAQLybgP/UQse39i+9tcte043CqeQ36kdyFM0Xesq q1EkG90HonLc/YS8XOXj7jsGN+WZ7W8jP7zAev6cmBJNUcKOPYJAhTCBfhelRLsN fviC+dc3WkhQjdVXEcQ18I5O3NykvhgtSfMOyBO521c9HIRSLTYecNRni4gHrzyr /wVUENzom/w= =0xiv -----END PGP SIGNATURE-----
On 9/17/06 8:01 PM, "Barry Warsaw" <barry@python.org> wrote:
BTW, what do you think about changing the way we hold messages for digests? E.g. instead of putting them in an mbox file, where it's more difficult to skip bad messages, stick them in a queue-like directory and pull them from there. Any messages that can't be read and scrubbed would just be removed.
Might be too big a change for the 2.1 series, but perhaps we should look at that for 2.2.
Sounds like a good change (with 2.2 being the earliest reasonable time to do it).
--John (cheering from the sidelines)
Barry Warsaw wrote:
BTW, what do you think about changing the way we hold messages for
digests? E.g. instead of putting them in an mbox file, where it's
more difficult to skip bad messages, stick them in a queue-like
directory and pull them from there. Any messages that can't be read
and scrubbed would just be removed.
I think this would be a great idea, and something like this will be necessary for the Association of Computing in the Humanities for whom I may be doing some mailman contract work.
Aside from the specifics that they want, this approach would allow for much easier implementation of custom digest approaches, like:
- send me a digest of only the Topics I care about
- similarly, send out Topic-specific digests
- let moderators edit digests, minimally selecting what gets included but maybe up to editing posts, reordering their occurence in the digest, providing summaries, etc.
None of this is impossible with mbox, but would be easier with maildir/queue.
~ethan fremen
Barry Warsaw wrote:
- the default build procedure is not suited to package building: it check target directory directly (which doesn't exist), and leave reference to package build root in python bytecode files. The patches [2] and [3] fixes those issues, maybe they could get integrated.
I don't think your links are correct. Link [1] is the same as link [2]. Sorry, here they are: http://cvs.mandriva.com/cgi-bin/viewvc.cgi/SPECS/mailman/mailman-buildroot-c... http://cvs.mandriva.com/cgi-bin/viewvc.cgi/SPECS/mailman/mailman-2.1.5-build...
- we have a patch for the embeded email module that just fix an encoding name [4]. I didn't found reference to a website or a standalone distribution of this module elsewhere. Could you please transmit the patch to its authors ?
There's no [4] link so I don't understand what this one tries to fix. The email package is developed at the email-sig: <http://www.python.org/sigs/email>. You should probably post the issue over there on that sig. The patch is http://cvs.mandriva.com/cgi-bin/viewvc.cgi/SPECS/mailman/mailman-2.1.8-Chars...
Just submited as bug #1556895 on python tracker.
BTW, why ship a private copy of this module instead of using the system one ?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sep 12, 2006, at 3:34 AM, Guillaume Rousse wrote:
Sorry, here they are: http://cvs.mandriva.com/cgi-bin/viewvc.cgi/SPECS/mailman/mailman- buildroot-check.patch?view=log http://cvs.mandriva.com/cgi-bin/viewvc.cgi/SPECS/mailman/ mailman-2.1.5-build.patch?view=log
Okay thanks, we'll look into these for a future release.
The patch is http://cvs.mandriva.com/cgi-bin/viewvc.cgi/SPECS/mailman/ mailman-2.1.8-Charset.patch?view=log
Just submited as bug #1556895 on python tracker.
Thanks, I've assigned this to myself.
BTW, why ship a private copy of this module instead of using the
system one ?
Because we can never be sure which version the system Python has and
we don't want to rely on a version we haven't vetted. The email
package is way too important to Mailman.
Thanks,
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRQbv3XEjvBPtnXfVAQLi0wQAmUyuZDeMIq3Z7WdJVucEbhcScF6+32O7 tyIKB3FnLvzlN1BUHMk1VXPRP5OnHT2jCfxyDBsuP6UVIa1zsjk+hwtVzxKZVVUm pIZDydmEGq3CjkNDVDxCMaaZZ72uyG1BzhZAw7iK2FEhm4cXoFR6xY2Jg1lWhfPY T8QccEmQZGs= =Gdmb -----END PGP SIGNATURE-----
participants (6)
-
???? -
Barry Warsaw -
emf -
Guillaume Rousse -
John W. Baxter -
Tokio Kikuchi