On 31 Jan 2011, at 16:56, Marc Perkel wrote: > You're trying to force feature that not everyone wants. I think it's a > bad idea. You can't assume that everyone is running in an environment > like what you imagine. It just becomes a pain in the ass for those who > don't want your artificial restrictions.
Mr Perkel, The dent in the wall over ----> there? That is from my head. Please, take pity upon the walls, and follow a simple rule: When people who work hard to maintain backwards compatibility in a product decide that it is worth breaking backwards compatibility, spend some time thinking about _why_ they might have done so, instead of assuming that they're stupid/uncaring/whatever. Unix systems programming is predominantly done in C, a language which leaves programmers prone to slips permitting remote code execution. Phil Hazel did a *great* job with Exim, avoiding most of the pitfalls and writing safe code. With Exim 4, he improved things further over Exim 3, by dropping entire models of execution which had been proven unsafe. But great as he is, Phil Hazel is not a god. It's a shock, but he's imperfect. Further, the current maintainers are imperfect too. Tony Finch appears to be striving for godhood in coding -- it must be something about the University of Cambridge -- but I know that I make mistakes. Releases of Exim until 4.70 contained a remote code execution bug. Someone in the blackhat community developed an exploit tool which would exploit that to run code as the Exim run-time user, and then use a design flaw in Exim to run code of their choosing as "root", thus compromising a system. Because 4.69 and some other earlier releases were still in widespread use, and the Maintainers did not call out widely "hey, buffer overflow, you maintainers should backport this one", a lot of systems in the "wild" were vulnerable long after we'd issued releases which fixed the initial hole. We are not gods. We should not assume we are perfect. The only safe assumption is that somewhere else in Exim there is another remote code execution flaw. A subtle one, to have remained hidden all this time, but still there. The next time it happens, users of Exim should be confident that the only impact was access to the Exim run-time user and that they can be safe updating just Exim and will *not* need to reinstall the operating system from trusted media. Security of the systems of those who trust us by running code we maintain is one of the very few reasons that we break backwards compatibility. Those who wish to run insecurely are responsible for maintaining the patches to Exim to do so. Note that until recently the Exim docs strongly discouraged using "root" as the run-time user for Exim, but it wasn't forbidden. Some people did so anyway. We no longer support that, and likewise force those people to maintain local patches. That actually went in *before* the exploit was known, but was an easy argument to make -- we will not support known-bad configurations of Exim. If you insist on shooting yourself in the foot with a miniature tactical nuke, we not only require you to disengage the safeties, we require you to actively modify Exim to remove the built-in safeguards. You are free to do so, this is open source, it's your system, modify it as you wish. But if you do so, you're unsupported and when things break, it's entirely your fault. Regards, -Phil -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
