4 ms·

I've spent significant time reading DJB's source, particularly daemontools. It makes me sad that programmers in this decade don't seem to be taking that much i

by chubot 12y ago

I've spent significant time reading DJB's source, particularly daemontools. It makes me sad that programmers in this decade don't seem to be taking that much influence from him. Commercial software is hopeless in terms of bloat and security holes. Open source software is sadly not that much better. The whole motivation for djbdns was all the glaring holes in BIND, and I think the same is true for qmail and sendmail. Yet basically every institution in the world is running a pile of sloppy software that dumps our private data to hackers on command. There is a lot to learn from djb. He's about 10-20 years ahead of his time, and you have to read code to absorb the wisdom. Here is some text that my help: http://thedjbway.b0llix.net/ http://thedjbway.b0llix.net/ http://lwn.net/Articles/257004/ http://lwn.net/Articles/257004/

davidw 12y ago
> It makes me sad that programmers in this decade don't seem to be taking that much influence from him. For a while, his stuff had weird licensing: http://en.wikipedia.org/wiki/Qmail#Copyright_status http://en.wikipedia.org/wiki/Qmail#Copyright_status
- protomyth 12y ago
  Yeah, it was confusing enough that qmail was dropped from the OpenBSD ports tree.
  - danudey 12y ago
    The Debian packages were scripts that downloaded, compiled, repackaged, and installed qmail for you, which was a giant mess but the only real way to make it work (license-wise).
walterbell 12y ago
DJB is contributing to a security research OS called Ethos, https://www.ethos-os.org/ https://www.ethos-os.org/ Papers: https://www.ethos-os.org/papers.html https://www.ethos-os.org/papers.html
nanofortnight 12y ago
I found his postmortem of qmail interesting reading: http://cr.yp.to/qmail/qmailsec-20071101.pdf http://cr.yp.to/qmail/qmailsec-20071101.pdf
- nimrody 12y ago
  Interesting to read that djb is in favor of automatic exception handling rather than explicitly checking return codes: "Fortunately, programming languages can—and in some cases do—offer more powerful exception-handling facilities, aborting clearly defined subprograms and in some cases automatically handling error reports. In those languages I would be able to write stralloc_cats(&dtline,"\n") or simply dtline += "\n" without going to extra effort to check for errors. The reduced code volume would eliminate bugs; for example, the bug “if ipme_init() returned -1, qmail-remote would continue” (fixed in qmail 0.92) would not have had a chance to occur." Contrast this with the explicit error handling promoted by Go (and used in djb's software due to lack of exception handling in C).
  - dilap 12y ago
    "Well defined subprograms" is key here -- in a mutable language like Go, goroutines are not well-defined subprograms, so exceptions are tricky to use correctly. Edit: I should clarify that's just speculation/personal opinion on my part. I'm not sure what djb had in mind.
  - danudey 12y ago
    That's the philosophy in Python. Instead of checking if you can do something ahead of time, just do it. If it fails, handle it then. This results in significantly cleaner code, since you generally assume that the code you're writing is going to run correctly (e.g. that you can successfully create a directory in /tmp/ or a pidfile in /var/run). Python, however, is also dynamically typed, which means that a lot of code is going to run even if you get unexpected input (e.g. 'print "this variable is %s" % somevar' is going to do a reasonable thing for pretty much every possible value of somevar), but it also means that your code might do something with invalid input which only makes sense if you know that your input was invalid (e.g. 'y * 10' is 20 if y is 2, or "2222222222" if y is "2"). C doesn't have that flexibility/curse, so it wasn't really an option for DJB.
gadders 12y ago
For anyone else who didn't know, he wrote this Daemon Tools: http://en.wikipedia.org/wiki/Daemontools http://en.wikipedia.org/wiki/Daemontools not this Daemon Tools: http://www.daemon-tools.cc/ http://www.daemon-tools.cc/
drzaiusapelord 12y ago
We're probably in some kind of security dark age right now where our tools just aren't good enough to automatically fix things and from a political/business/market pov, we don't have the incentives to write truly secure software. I imagine things like Rust are going to help in the near future. Just handling all these buffer overflows is going to make a fairly big difference in computer security. I also imagine things like IPS's are going to trickle down to client devices like laptops and phones. We have enough extra CPU power to check every packet for known exploits and pro-actively stop things like XSS or SQL injections. We are also probably looking at the dawn of the locked down desktop that can only access installable software from the OS store which will deliver only signed and vetted software. Our largest exploit right now is just being able to send someone a hyperlink to trojan.exe and having them run it. End users will always fall for that unless the OS stops them. A higher level of app security and app behavior nannying is probably coming our way. If you have a Windows machine you can install EMET right now. There are rumors EMET's functionality will be baked into Win10. This period reminds of the pre-Nader peroid in American automotive history. Manufacturers competed on HP, large sizes, etc and not on safety, efficiency, etc. We're asking for the wrong things. Now that things like low power chipsets, SSDs, and multi-cores are the norm, its time for the industry to focus on security. It'll get there -- dragged, kicking and screaming eventually. Especially in the age of bitcoin which makes Cryptolocker ransomware payments anonymous. More code reviews and more forks and clones aren't going to win this. There needs to be a holistic change in how we create and deploy software and this change needs to be in demand. The real question is, are we incentivized to make this change yet? Why aren't we asking for better security?
agumonkey 12y ago
I can't find them again, but I remember seeing design diagrams from djb's qmail. His approach to system design is pretty great IMHO, it's pragmatic, minimalist, language/paradigm agnostic.

by chubot 12y ago

davidw 12y ago

> It makes me sad that programmers in this decade don't seem to be taking that much influence from him. For a while, his stuff had weird licensing: http://en.wikipedia.org/wiki/Qmail#Copyright_status http://en.wikipedia.org/wiki/Qmail#Copyright_status

protomyth 12y ago
Yeah, it was confusing enough that qmail was dropped from the OpenBSD ports tree.
- danudey 12y ago
  The Debian packages were scripts that downloaded, compiled, repackaged, and installed qmail for you, which was a giant mess but the only real way to make it work (license-wise).

walterbell 12y ago

DJB is contributing to a security research OS called Ethos, https://www.ethos-os.org/ https://www.ethos-os.org/ Papers: https://www.ethos-os.org/papers.html https://www.ethos-os.org/papers.html

nanofortnight 12y ago

I found his postmortem of qmail interesting reading: http://cr.yp.to/qmail/qmailsec-20071101.pdf http://cr.yp.to/qmail/qmailsec-20071101.pdf

nimrody 12y ago
Interesting to read that djb is in favor of automatic exception handling rather than explicitly checking return codes: "Fortunately, programming languages can—and in some cases do—offer more powerful exception-handling facilities, aborting clearly defined subprograms and in some cases automatically handling error reports. In those languages I would be able to write stralloc_cats(&dtline,"\n") or simply dtline += "\n" without going to extra effort to check for errors. The reduced code volume would eliminate bugs; for example, the bug “if ipme_init() returned -1, qmail-remote would continue” (fixed in qmail 0.92) would not have had a chance to occur." Contrast this with the explicit error handling promoted by Go (and used in djb's software due to lack of exception handling in C).
- dilap 12y ago
  "Well defined subprograms" is key here -- in a mutable language like Go, goroutines are not well-defined subprograms, so exceptions are tricky to use correctly. Edit: I should clarify that's just speculation/personal opinion on my part. I'm not sure what djb had in mind.
- danudey 12y ago
  That's the philosophy in Python. Instead of checking if you can do something ahead of time, just do it. If it fails, handle it then. This results in significantly cleaner code, since you generally assume that the code you're writing is going to run correctly (e.g. that you can successfully create a directory in /tmp/ or a pidfile in /var/run). Python, however, is also dynamically typed, which means that a lot of code is going to run even if you get unexpected input (e.g. 'print "this variable is %s" % somevar' is going to do a reasonable thing for pretty much every possible value of somevar), but it also means that your code might do something with invalid input which only makes sense if you know that your input was invalid (e.g. 'y * 10' is 20 if y is 2, or "2222222222" if y is "2"). C doesn't have that flexibility/curse, so it wasn't really an option for DJB.

gadders 12y ago

For anyone else who didn't know, he wrote this Daemon Tools: http://en.wikipedia.org/wiki/Daemontools http://en.wikipedia.org/wiki/Daemontools not this Daemon Tools: http://www.daemon-tools.cc/ http://www.daemon-tools.cc/

drzaiusapelord 12y ago

We're probably in some kind of security dark age right now where our tools just aren't good enough to automatically fix things and from a political/business/market pov, we don't have the incentives to write truly secure software. I imagine things like Rust are going to help in the near future. Just handling all these buffer overflows is going to make a fairly big difference in computer security. I also imagine things like IPS's are going to trickle down to client devices like laptops and phones. We have enough extra CPU power to check every packet for known exploits and pro-actively stop things like XSS or SQL injections. We are also probably looking at the dawn of the locked down desktop that can only access installable software from the OS store which will deliver only signed and vetted software. Our largest exploit right now is just being able to send someone a hyperlink to trojan.exe and having them run it. End users will always fall for that unless the OS stops them. A higher level of app security and app behavior nannying is probably coming our way. If you have a Windows machine you can install EMET right now. There are rumors EMET's functionality will be baked into Win10. This period reminds of the pre-Nader peroid in American automotive history. Manufacturers competed on HP, large sizes, etc and not on safety, efficiency, etc. We're asking for the wrong things. Now that things like low power chipsets, SSDs, and multi-cores are the norm, its time for the industry to focus on security. It'll get there -- dragged, kicking and screaming eventually. Especially in the age of bitcoin which makes Cryptolocker ransomware payments anonymous. More code reviews and more forks and clones aren't going to win this. There needs to be a holistic change in how we create and deploy software and this change needs to be in demand. The real question is, are we incentivized to make this change yet? Why aren't we asking for better security?

agumonkey 12y ago

I can't find them again, but I remember seeing design diagrams from djb's qmail. His approach to system design is pretty great IMHO, it's pragmatic, minimalist, language/paradigm agnostic.