"I expect this strategy to produce invulnerable computer systems: restructure programs to put almost all code into extreme sandboxes; eliminate bugs in the small volume of remaining code. I won’t be satisfied until I’ve put the entire security industry out of work."
It sounds incredibly audacious until you consider the number of security holes discovered in qmail after all these years: one, and it wasn't exploitable on any existing computer system.
How much worth is a secure software if it quickly becomes outdated and thus useless? (at least in its original, secure form)
Qmail is an example of how to success in security, but then fail another way. DJB never reviewed contributed features, or reimplemented them the "right/secure way". There was absolutely no plan to evolve Qmail, so it was unable to fit future requirements.
This catastrophic project management literally provoked forks and patches. People had to modify the original Qmail to get even basic features such as SMTP authentiation or integration with spam scanners. Many patches of questionable quality are flying around, and no official next version of qmail.
So to be fair, we should count the bugs in the Qmail forks (e.g. qmail-ng), because these are the versions that are actually used.
sort of? see http://dnscurve.org/ - but it doesn't entirely address the same problem as dnssec. DJB looks like he took the parts he could do better and did them better while leaving key management (which some people claim is the hard part) to the user.
there was a discussion of it on dns-operations[1] the other day
Chrome's (and soon Firefox's) out-of-process plugins are a tiny step toward the mainstream, but still just a fraction of djb's ideas. He wants to sandbox all pure "transforms" - HTML parsing, CSS parsing, image decoding, gzip decompression, etc. - and put them into not just another process but one without any normal user privileges.
The ideas are kind of implemented in Haskell, if that counts.
Every pure transformation (i.e. function) in Haskell is safe from side effects. There is a very clean and safe separation beween pure and impure code. So an operating system based on Haskell, with a Haskell shell and the like, would be a very secure environment.
Of course, that means the Haskell compilers and interpreters have to be secure, but the same holds for C compilers, too.
I wonder how much work it would take to convert MS Singularity or Renraku from .NET to Haskell... sounds like (the research would be) a fun weekend project :)
For further thoughts on limiting bugs and their consequences, see his paper "Some thoughts on security after ten years of qmail 1.0" (http://cr.yp.to/qmail/qmailsec-20071101.pdf).
For all the "you may know about Bernstien because... " stuff at the beginning of the article, I can't believe "because he's a pretentious, self-important douche" didn't make the list. And it's not that it's completely and totally undeserved. The dude is sharp. I just prefer it when people let others pile the accolades on. And they would come if he didn't toot his own horn so much. His rants typically leave a bad taste in my mouth. His quotes here are not exceptions to this rule.
