Bugzilla Bug 103894

Exim ships its own (affected) copy of the libpcre library. See bug 103337 for
details on the vulnerability. There probably aren't much use of parsing of
untrusted PCRE in exim, but it should be fixed nevertheless.

The idea would be to make exim build against the system libpcre rather than
using the internal copy, which doesn't seem to be the case at the moment.

Ccing maintainers for inputs.

Thanks for the heads up, As I understand it you have to be running some PCREs
at SMTP time to be 
vulnerable, and i believe the default config (as shipped by gentoo), doesn't
contain any PCREs.
Upstream has fixed the issue in the snapshot, and I'm expecting a fixed release
soon.

I could potentially backport the fixes, but i'd rather let someone else come up
with a patch against 
4.52, however i suspect 4.53 will be released before then.

Another solution would be to link directly against the external libpcre
library, but that's a fair chunk of 
changes to the ebuild, and means shipping a redundant copy of the code (ie in
the source tarball), and 
there will then be a backlash from that.

If any more information comes to light, i'll look into it again, but as it
stands, i'd like to wait until 
upstream releases their fix(es) (we can put the next version on accelerated
release path and mask lower 
versions if needs be).

Setting status to 'wait for upstream', downgrading severity

At some point I guess it would be nice if it linked against the external 
libpcre lib. 

(In reply to comment #3)
> At some point I guess it would be nice if it linked against the external 
> libpcre lib. 

Please see para 4 in coment #1 for the main reasons why this won't be done any time soon unless 
absolutely necessary.

peitholm, it was a future request not a task for this bug. 

4.53 is out.

Colin does 4.53 solve this issue? 

I believe it does, 4.53 should be hitting the tree soon, it needs some testing,
and i'm out tomorrow, but 
hopefully tomorrow evening.

4.54 is in.
Fixed PCRE (v6.2) is included since 4.53.

Arches should test and mark stable...

Target final KEYWORDS="x86 sparc hppa alpha amd64 ppc ia64"

Given that exploitation possibility is not obvious, you can take your time and
keyword "~" first if you prefer.

Why on earth were all the keywords removed ?

Maybe someone has to re-read our keywording policy ?

which arch keywords in specific ferdy? (so i know which archs your a member
off, it's not listed on the dev 
list).

my personal policy has been that i will only add a keyword that I personally
have tested on, and given no 
one has said anything for a long time now... (looking at
http://www.gentoo.org/proj/en/devrel/
handbook/handbook.xml?part=3&chap=1 I see that my approach is wrong so i'll
comply even though i 
don't agree with current policy on this). 

koon, there are dependancies that haven't get been tested so it's not ready to
go stable... I'll draw up a list 
of these tonight. but its breifly the spf/srs stuff (which no arch has yet
marked stable).

In my particular case is alpha, but I see other keywords beeing dropped. In the
future if you want us to check that something works file us a bug and we'll
gladly test the package.

Cheers,
Ferdy

I keyworded ~alpha libsrs_alt-1.0_rc1-r1, libspf2-1.2.5-r1 and exim-4.54

Though libspf2 seems to work fine, the test suite is failing, is it suposed to
work ? (I can provide an excerpt if needed)

Cheers,
Ferdy

Forget to remove hppa from cc. Do it now.

For the first pass :

amd64 should add ~amd64 to exim-4.54 when they keyword libspf2 the same.
ia64 should add ~ia64 to exim-4.54 when they keyword libspf2 and libsrs_alt the
same.

Then when sufficient time is spent in ~, feel free to keyword all stable.

Please test and mark exim 4.54 / libspf2 / libsrs_alt stable
Target KEYWORDS="amd64 alpha hppa ia64 ppc ~ppc64 sparc x86"

alpha done

Stable on ppc and hppa.

stable on x86

amd64 stable

sparc stable.

Since this has no known security consequences (but is more a preventice thing),
no GLSA is needed.
Feel free to reopen if you disagree.