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.
