Tracy R Reed wrote:
One of the most interesting arguments he makes in this paper is that we should not be using relatively low level languages like C to write things like mail servers. He says security is much more important than speed. I agree. Especially for things like qmail/sendmail which spend the vast majority of their time waiting on IO instead of waiting on cpu.
Ayup.
He does say least privilege is not as important as we think. I tend to disagree with that. The example he cites is one case where least privilege doesn't help that much but in many other cases it is critical.
Maybe, but what I took away from it is that you have to think about making programs operate with only the minimal privilege that they start out with.
His example of the mail parser was instructive. The only thing that the person composing the email address could modify was the output of the email address--which was something they could modify *anyhow* since they were the ones who composed the original email address.
A lot of programmers don't like to interrupt the flow of their coding and just write big long functions to get things done and then never go back to refactor.
Uh, really? I *rarely* write big long functions when I am "in the flow". And, normally, refactoring is *easier* when I have just written the same lines 3 or 4 times running in recent memory rather than spread over several days.
In 4.1 he mentions factoring things out, especially little utility functions, as a means of improving quality. I have known certain perl programmers who hated to pull out just 4 lines of their code into a standalone function.
Well, that's because refactoring in languages like C, C++, and Perl is *painful*.
There is something to be said for languages that have context-free parsing semantics.
This could be better than trying to write a bunch of C code to detect and prevent all manner of errors.
Only death errors. Erlang is still subject to errors that don't kill the process like corrupted state. In addition, you have to design your *other* processes to cope with the fact that something they are talking to may get blown away at any time.
DJB says he probably should have written it in another language and then translated it to C for distribution. But I don't see how this is any better than just distributing some other high level language which has interpreters for pretty much all common platforms.
Because you need the interpreters and even the fastest interpreters would still probably be too slow for qmail under high-load. There is a spectrum of available solutions.
On one side, you have Lua which tries to maintain the smallest possible core and is purely ANSI compliant--it's also probably the fastest interpreter around. However, you need to compile and tack on libraries to do anything useful. On the other side, you have something like Gambit-C, which is Scheme that compiles completely down to really complicated C code, but is completely full featured and gets full C speed when it can avoid diving into the interpreter.
Section 5.2 makes a good point and basically uses a functional programming idea to sandbox calculations such as rendering a jpg into a bitmap avoiding potential exploits caused by malicious data. Expensive to do in a Unix style process but perhaps not so bad in a sandboxed thread in a virtual machine like Erlang or Java.
I thought the whole point he was making in the paper was that you should pay the expense and worry about optimization later. One of his points was that he should have actually grabbed the filesystem code and fixed *that* rather than writing an application level workaround.
The idea that you should recognize certain patterns as a deficiency of the operating system was one of those "bloody obvious" bombshells that is only obvious in retrospect--and only possible with open source OS systems.
Overall a very interesting paper.
Yes, it was.
It is fun to see DJB actually humble himself a bit and admit to errors made in the initial Qmail design and suggest fixes. Qmail is still an amazing accomplishment due to having the complex functionality of an MTA while pretty much zero bugs over the last 10 years. I really can't name another project with such a track record.
Probably some of the applications that the OpenBSD guys have put together are comparable (OpenSSL and OpenSSH spring to mind).
Alas, these shining examples are far too few. -a -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
