Thus spake Mate Wierdl ([EMAIL PROTECTED]):
> I thought it was possible that Dan would give some hints on his view
> on secure programming in these notes.
Don't talk.
Read his code and you will understand.
> > Software is secure iff the architecture and trust model is sound, which
> > you can verify yourself in a few hours.
> You make software security look easy, and Schneier's book tells me
> otherwise.
Software security _is_ easy.
The correct paradigms have been published for decades.
It is only non-trivial to write good (and secure) software if you use
legacy APIs that make it unnecessarily hard on you. That's why Dan
decided to not use many routines from the standard C library. Actually,
he has written many notes on his reasoning, you just have to look
instead of posting here and thinking that maybe others do the work for
you.
> 1) It seems that systematic (scientific?) testing of qmail
> or djbdns has not happened---except by Dan.
Had you actually read the Schneier, you would know that no testing in
the world can prove the security of a system. Testing can only prove
that a system is not secure.
> 2) The only way we could get a hint on the guiding ideas of Dan on
> secure computing is to read the source code he writes.
Or you could read a few books or papers about security.
The guidelines are easy and easily understood and implemented.
For example, minimizing the trusted computing base and
> But this is reverse engineering, and is similar to trying to
> undertand Gauss's ideas by reading his proofs---good luck.
Reconstructing the source code from a binary program is reverse
engineering. Reading the source code is not.
And source code is a formal representation of an algorithm, not a proof.
An algorithm would tell you how to prove something. Understanding Gauss
by his proofs is like understanding djb by looking at an RPM. It is
still possible, by the way, because the man pages are great.
> Or does everybody on this list who read qmail's sources is writing
> 100% secure software now?
Why don't just read the sources yourself and find out?
> Does everybody have a clear idea what Dan considers a security
> problem?
A buffer overflow on the stack, for example.
> For example, he clearly does not care about preventing some
> DoS attacks.
Your oversimplifications border on intention deconstructivism.
Read his fscking web pages and find your questions answered.
Felix
