Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

2006-05-23  Mr. Sam  <mrsam@courier-mta.com>

        * courier/libs/comverp.c (verp_encode): Fix bug in encoding of
        usernames that contain '='.

bug 134262 is the same bug.

This bug sould be merged with bug 134262 and bug 134262 sould be assigned to
security team, so that the security process could be completed, including the
final GLSA vote.

it is   CVE-2006-2659

*** Bug 134262 has been marked as a duplicate of this bug. ***

swtaylor please advise and patch as necessary.

Perhaps someone from net-mail will help on this one?

Vapier/Solar/Taviso no response from mail to swtayloer, will you try a bump?

mail-mta/courier-0.53.2 is in the tree now, which fixes the security issue and
a few other bugs, thanks to Marcin Semeniuk (a user) that provided updated
ebuilds in another bug. I want to stress that I only did the version bump for
security, I won't maintain mail-mta/courier myself as I don't use it anywhere.
Best regards, CHTEKK.

Thx Luca.

Arches please test and mark stable.

forgetting you have courier working locally = doh!

x86 done, as it all worked for me in that reguards. I'm going to take a nap
now.

Z_Z

courier dies if "test" is in FEATURES because something it does via make check
spits out;

Making check in imap
make[1]: Entering directory
`/var/tmp/portage/courier-0.53.2/work/courier-0.53.2/imap'
make  check-am
make[2]: Entering directory
`/var/tmp/portage/courier-0.53.2/work/courier-0.53.2/imap'
=============================
Do not run make check as root
=============================
make[2]: *** [check-am] Error 1
make[2]: Leaving directory
`/var/tmp/portage/courier-0.53.2/work/courier-0.53.2/imap'
make[1]: *** [check] Error 2
make[1]: Leaving directory
`/var/tmp/portage/courier-0.53.2/work/courier-0.53.2/imap'
make: *** [check-recursive] Error 1

!!! ERROR: mail-mta/courier-0.53.2 failed.
Call stack:
  ebuild.sh, line 1539:   Called dyn_test
  ebuild.sh, line 987:   Called src_test
  ebuild.sh, line 618:   Called die

Will continue testing, but should be disabled.

Created an attachment (id=91607) [details]
Updated mailer.conf for mailwrapper support

At the request of langthang, I re-built courier with FEATURES="userpriv test"
and the tests run fine.

On another note, the mailer.conf file for USE="mailwrapper" support provided in
${FILESDIR} is broken.  The path to sendmail.courier has changed from /usr/sbin
to /usr/bin.  Attached is an updated version of it with the right pathings.

mailer.conf was updated as per attachment and the ebuild had a src_test added
that will only execute the tests if FEATURES="userpriv" is present, else it
will warn the user about the need of it to make check.
Best regards, CHTEKK.

SPARC sexy

This time I'll even remove SPARC from the CC! :)

Your hourly bug spam brought to you by jforman's goats.

Could someone investigate the missing patch that should (?) get applied w/
USE="-fam"? (Bug 140883) AFAICS that patch just never existed.

(In reply to comment #16)
> Could someone investigate the missing patch that should (?) get applied w/
> USE="-fam"? (Bug 140883) AFAICS that patch just never existed.
> 

it looks like swtaylor bumped courier-0.48.2.20050130.ebuild to fix bug #69630
but forgot to commit fam-disable-check.patch.
http://sources.gentoo.org/viewcvs.py/gentoo-x86/mail-mta/courier/courier-0.48.2.20050130.ebuild?hideattic=0&rev=1.3&view=markup
one can port that patch from courier-imap but as far as security concern this
isn't a regression.

BTW, tsunam mark 52.2 x86 instead of 53.2. re-add x86.

(In reply to comment #17)
> as far as security concern this
> isn't a regression.

I take it back. The last known stable ebuild doesn't have that fam stuff in
there.  Guess we have to yank fam related stuff out and do a revision bump
later with fam goodness.

bug 140883 is fixed. please back to your regular schedule. Sorry for the
interruption.

perhaps its the right version this time.

Already ppc stable.

alpha stable.

forgot to remove us.

amd64 done, sorry for the delay.

I tend to vote YES.

usernames containing '=' ?? Voting no.

recipients with = seem pretty uncommon... nevertheless i tend to vote yes on
this one (a really small yes though)

I'd say it would depend on whether usernames would have to be *valid*. If NOT,
I'd vote YES. But I couldn't find info that anywhere.

Can somebody who actually worked on the code tell?

Mail gateways or mailing list servers usually don't have any chance of
validating the username.

i vote no; username with "=" is rather uncommon, isn't it ?

Sune is right IMHO (#29), and I vote "yes", too, because of that.

Reverting to yes.

ia64 don't forget to mark stable to benifit from the GLSA.

GLSA 200608-06