The Grumpy Troll

Ramblings of a grumpy troll.

Exim: novel experiences

Last year I became an Exim Committer. I shepherded the recent 4.74 release, which was the first one not done by The Usual Victim. As such, there were some teething issues, but it went okay.

Unfortunately, it was a security-fix release, which meant that it was done on a compressed schedule. I'd much rather my first Exim release not have been so constrained, but that's the way the dice rolled and I just have to suck it up. So there were a couple of issues not caught in the limited RC (Release Candidate) window.

Thus I've been dealing with being the releaser of widely-used software with changes which did not get tested on sufficiently old platforms as people discover that, for their system a small patch is needed. One reaction is to ask when the next release will be, and I need to patiently explain that if they didn't test an RC then they don't get a new release just for their platform, otherwise we'd just be constantly issuing more releases, creating an upgrade burden on the people who do test RCs and like to stay up-to-date. Laziness taxes should be paid by the lazy, not be externalised to the industrious. Note that this is a rather unfair attitude on my part for this release, as the RC window was small, so there was much less time for testing, but people could at least try to compile on their platform!

Today's novel experience: Debian issued the DSA-2154-2 advisory for their updated security fix release breaking the ability of users to test their ~/.forward files with { exim -bf }. This came as news to me, so I investigated. The Debian bug-tracker entry for bug 611572 contains the details. The fix? One of my updates to the Exim code, which was included in Exim 4.74.

Note for this next bit: my gripe is very minor and really just a commentary upon an unfortunate situation. I doubt things could have gone better.

For the 4.74 release, I figured out an attack scenario against an unchecked return code of a setuid() call; this attack only works on Linux, since only Linux lets an untrusted user manipulate the environment to affect a security-critical trust transition of the superuser account. The initial fix was too aggressive, I moderated the impact in a second fix. Both of these together went into 4.74, including even the first RC. So, users of Exim releases never encountered this regression. The novel experience is seeing what happens when people back-porting fixes miss something. It's a hard job, tracking all the changes and figuring out what to backport, but really this just argues that Debian's policy is perhaps too strict with software that has a very strong policy of not breaking backwards compatibility. But it's their OS and their policy and their call, as the people doing the work of maintaining the OS. Still, I could have done without the momentary panic of "what did I eff up now?" and with their release announcement making it clearer that the regression was Debian-specific.

Ah well. Novel experiences are part of the rich tapestry of life. :)
-The Grumpy Troll
Categories: backport exim release Debian security