16 ms·

Aaron Swartz's Thoughts on djb (2009)

271 points by cookrn 12y ago

jewbacca 12y ago
qmail 1.03 source mirror on github: https://github.com/amery/qmail/tree/aa6bf9739209ca76f7f3af0feada5552723a622b https://github.com/amery/qmail/tree/aa6bf9739209ca76f7f3af0f...
- stormbrew 12y ago
  Which, in spite of its 'perfection', it should be noted that you should not run unpatched on a public facing server (or at least not qmail-smtpd), lest you become an unwitting backscatter zombie. I love djb's software, and I love his way of looking at things, but no software stays perfect forever.
  - e12e 12y ago
    Had to look up what a backscatter zombie was; apparently it's what happens when you accept bogus mail (spam) into your mail queue without checking if it is actually deliverable -- thus end up bouncing it once the queue is processed for delivery -- and typically then sending it back to a forged address -- ie: you become a spam gateway (spammers send you email with sender-addresses they want you to try to send spam to...): http://serverfault.com/questions/111938/how-might-i-stop-backscatter-using-qmail http://serverfault.com/questions/111938/how-might-i-stop-bac...
jaryd 12y ago
I appreciate this as an avid user of daemontools (http://cr.yp.to/daemontools.html http://cr.yp.to/daemontools.html) -- thanks for the link!
- geoka9 12y ago
  Daemontools is a gift from the unix gods. Having been a unix user for most of my professional life, I haven't even heard of it until a project for which it was exactly what I needed. When I found it, within an hour I was ready to deploy with all my requirements met and the best of it - it all worked as any experienced unix user would expect it to be! (And I don't remember even skimming the man page.)
chrisdew 12y ago
Perhaps people are annoyed that DJB does everything his own way, rather than using standard tools? I vaguely remember building DJB's software from source to be non-trivial, but that was a decade ago.
- deleted 12y ago
  [deleted]
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
ohsnap 12y ago
DJB had some great comments on what he thought makes qmail secure: http://cr.yp.to/qmail/qmailsec-20071101.pdf http://cr.yp.to/qmail/qmailsec-20071101.pdf Perhaps the most legit complaint of DJB's work is that he would often lobotomize chunks of a protocol if he didn't like it. But it was still great work and it contrasted nicely to some horribly insecure software at that time (sendmail and bind)
- cousin_it 12y ago
  That's an amazing paper, thank you for linking to it! I actually learned something new from it, in particular the sections 5.1 "Accurately measuring the TCB" and 5.2 "Isolating single-source transformations". It turns out there's a wrong way and a right way to do "privilege minimization" for security, and all my life I've been thinking about it the wrong way.
  - acqq 12y ago
    It also shows that the resulting "bug-minimal" code didn't just spring out of nothing but is the result of a lot of experience even two decades ago: "I started writing an MTA, qmail, in 1995, because I was sick of the security holes in Eric Allman’s “Sendmail” soft- ware." djb even then analysed the security aspects of the bugs. And spent the considerable time working on the solutions: "My views of security have become increasingly ruthless over the years. I see a huge amount of money and effort being invested in security, and I have become convinced that most of that money and effort is being wasted. Most “security” efforts are designed to stop yesterday’s attacks but fail completely to stop tomorrow’s attacks and are of no use in building invulnerable software. These efforts are a distraction from work that does have long-term value." BTW the "TCB" was never explained in the article but I guess he means "trusted computing base."
gitemacs 12y ago
I disagree with Aaron. I would reserve the title of the greatest programmer in the world to Fabrice Bellard. He single-handedly wrote QEMU, FFMPEG, an LTE base station, a PC emulator in javascript, and countless other projects. Alone. http://bellard.org/ http://bellard.org/
- sanxiyn 12y ago
  djb aims to write bug-free programs and actively works on improving the process to do so. While Bellard is a great programmer, I don't think Bellard aims to write bug-free programs. See section 8 of http://cr.yp.to/cv/activities-20050107.pdf http://cr.yp.to/cv/activities-20050107.pdf There are more people who aims to write bug-free programs, but most of them seem to use formal verification. djb seems pretty unique in aiming bug-free programs in normal programming and getting close. Re: Bellard software quality. Fuzzing found 1120 bugs in FFmpeg. While Bellard's code is only small part of entire FFmpeg, FFmpeg is very far from being bug-free. http://googleonlinesecurity.blogspot.com/2014/01/ffmpeg-and-thousand-fixes.html http://googleonlinesecurity.blogspot.com/2014/01/ffmpeg-and-...
  - schoen 12y ago
    I was shocked (and impressed) when I looked at some of djb's code and saw that he put his "the return value of every syscall must be checked" view into practice so consistently that every single printf() (not only fprintf()!) was inside an if block that checked whether it succeeded in writing to stdout or not. Of course, printf() does have a return value ("Upon successful return, these functions return the number of characters printed"), and it can fail... but it takes a considerable consistency of purpose to decide to deal with that possibility explicitly every single time.
    - riffraff 12y ago
      out of curiosity, what do you (does he) do if printf fails?
      - svckr 12y ago
riffraff 12y ago
I have vague memories of the fact that qmail was mostly used with patches that DJB didn't want to incorporate, (e.g. support for STARTTLS). This ended up causing a lot of people to use other servers which _did_ respond to user demands. So maybe other than only learning from the way he writes code, we can also get some ideas on how to nurture open source projects.
- pixl97 12y ago
  DJB wasn't exactly wrong about TLS, it's been an unending source of security holes for a while now and everybody that's looking at the code expects more. Most of his work is actually dealing with encryption and pointing out flaws in implementations like DNSSEC (which provide no security to the end client).
- MichaelGG 12y ago
  There's also the licensing, preventing distros from using their own directory layouts. djb says they're being ridiculous and his folder layout is superior (and it is). But it seems to have the opposite effect if it just means packagers decide to simply drop the software :(
  - tptacek 12y ago
    The software you're talking about is in the Public Domain.
    - raldi 12y ago
      Only since December 2007: http://en.wikipedia.org/wiki/Djbdns#Copyright_status http://en.wikipedia.org/wiki/Djbdns#Copyright_status http://en.wikipedia.org/wiki/Qmail#Copyright_status http://en.wikipedia.org/wiki/Qmail#Copyright_status The change was made because the situation was unfolding exactly as described above.
laurencerowe 12y ago
> But these programs are not just for being seen or read — like a graceful dancer, they move! This is what makes programming beautiful. The analogy that come most easily to me are to machines, like the wonderful stationary engines that sometimes ran at the Manchester Museum of Science and Industry. But in comparison their movement is so constrained... Dancing is far more representative.
- agumonkey 12y ago
  I had the same issue with college classes about software design compared to skycrapers. In my mind software has always been much more dynamic. I'll admit I like them too dynamic (lisp, meta, reactive, context oriented, AI). But even carefully constrained software is moving. Biology is also very fitting.
hippiefahrzeug 12y ago
I've followed a policy of using djb's software whenever possible over the years. Unfortunately qmail shows its age and may no longer be a good choice these days, but then again, who runs their own email server? :) daemontools and ucspi-tcp are still some of the best tools to dig into. I love multilog (part of daemontools) which solves problems I didn't even know exist. e.g. I had a pool of servers and wanted to collect all the logs in one place... the way multilog names files makes this a simple rsync task, and you can just concatenate and sort, it even works for multi-lined output. Since I started using docker, djb's tools got a new life for me. I manage all services within docker containers with daemontools.
- davvid 12y ago
  Unfortunately qmail shows its age and may no longer be a good choice these days Last I checked, Yahoo (Mail) uses qmail. Can anyone verify whether that is still true today?
  - Arnt 12y ago
    Yahoo advertises TLS support, so the bulk of the code Yahoo uses will be third-party extensions, perhaps openssl.
- vidarh 12y ago
  Qmail may show its age, but the overall structure is sound, and one the beautiful parts of qmail was/is how it isolated everything in their own processes intercommunicating via very simple protocols over file descriptors. So you could build far more complicated mail systems by starting with qmail and replacing parts as you went. A company I co-founded used qmail for delivery for a webmail service for ~2m users, and while we used the original qmail less and less, it was because we were able to use qmail as scaffolding as described above. And we ran lots of services under daemontools. Later we used qmail as a generic message queueing system for a turnkey registrar platform for .name...
  - voltagex_ 12y ago
    Are you able to expand on how qmail was used / not used? I didn't think it was something that could be easily modified like that
geofft 12y ago
The bug thing is about security holes, right? I think the comparison with Knuth is apples-to-oranges. Or is it actually the case that, since the first public releases of djbdns and qmail, no bugs, security or otherwise, have been found?
- sanxiyn 12y ago
  As I understand, there has been less than 10 or so non-security bugs each in djbdns and qmail, defined as programming mistakes, not intentional design decisions people disagree with. This is comparable to (or even better than) Knuth. I don't think there is a handy list of bugs though.
- self 12y ago
  There have been several non-security bugs. So far, I think there has been just one security bug in djbdns: http://securityandthe.net/2009/03/05/security-issue-in-djbdns-confirmed/ http://securityandthe.net/2009/03/05/security-issue-in-djbdn...
drinchev 12y ago
Wow three letters, so many stories in my head. Here are my top 5 reasons why I think qmail + daemontools + djbdns is great : 1. bugs free code ( well almost ) ; 2. fast & memory efficient ; 3. following "everything is a file" philosophy ; 4. easy to configure and more I've been using this suite for almost 10 years now. I've never found any alternative. BIND was too complicated in terms of configuration for me and also got updates almost every 2 weeks ( 8 years back it was much much harder than doing "apt-get ..." ) Qmail is also flawless piece of software. It basically taught me how you should separate processes and how to use linux accounts properly for the daemons. Amazing. Finally the only thing I rely on right now is daemontools. I'm using it for all of my production nodejs websites and even for a tool that I call "deployer" which automatically stops, updates and starts a daemon from the suite.
- piranha 12y ago
  Sorry, 8 years ago it was 2007 and updating BIND was done precisely by doing 'apt-get ...'. I still have a server running same installation of Debian since 2005 (copied from one HDD to another and to a virtual server then), and it's been apt-get updated all the way through.
  - pixl97 12y ago
    I know you're having fun showing off how easy it was to update BIND, but how many times have you had to update it since that time? Now how many times did he have to update the DJB name server?
    - piranha 12y ago
      I don't know, I'm not counting them. And there is no doubt djbdns is better than BIND regarding security - it's just you can't use "8 years ago updating stuff was hard" as an argument, because it was not.
      - drinchev 12y ago
        8 years ago I was using slackware as my main server distribution. Yes there is no "apt-get ..." in slackware even nowadays, but back then debian switched to aptitude at around 2005 ( sarge ) [1]. I remember around 2010 I reached uptime 3 years on one of the machines, with my good old patched slackware 10. Now imagine me switching to "apt-get ..." because of "easy security updates" for a tool that lived less than my uptime was. Yes this is the time that I had to use exactly this argument, but against doing precisely that. 1: https://www.debian.org/doc/manuals/project-history/ch-detailed.en.html https://www.debian.org/doc/manuals/project-history/ch-detail...
joosters 12y ago
If only djb's programs would write human-readable log files...
- drinchev 12y ago
  If you are talking about the date, it's documented how to parse it : > cat current | tai64nlocal
  - joosters 12y ago
    Yes, it's the damn date. It doesn't matter how well documented it is, once you have to apply a conversion to logfiles before they can be easily read, you lose all your existing workflow. It becomes a pain to use. I never understood djb's aversion to using human-readable dates in the log files. It's not a lot of effort for the computer to produce or to consume them, so we really should push the effort onto the computer, and not onto the user.
    - drinchev 12y ago
      Yeah djb's way suggest we use TAI time format, because it's more accurate. Anyway I haven't found this to be so big of a hassle for me. And it sounds really cool what it's doing : > The standard timestamp used in "the djb way" is TAI, for Temps Atomique Internationale. It is an absolute measure of elapsed time based on the decay of cesium atoms, where one day is equivalent to exactly 86,400 TAI seconds. > But the actual rotation of the Earth does not exactly conform to the TAI idea of time. In fact the Earth is slowing down a little bit, so that each physical day is minutely more than 86,400 TAI seconds. > Our human notion of time is based on this physical day length, and is represented by the UTC timeclock. The UTC timeclock is intended to represent a clock that points exactly 12:00 noon when the Sun is directly overhead on the solstice at 0 degrees longitude. http://thedjbway.b0llix.net/leapsecs_update.html http://thedjbway.b0llix.net/leapsecs_update.html
      - MichaelGG 12y ago
        Yes, leap seconds are an abomination and something that should only exist for odd use cases, like astronomers or something. Forcing UTC into all software and civil use is vile. Hopefully UTC will stop getting leap seconds, or we'll move to something like UTC with no further leap seconds.
Animats 12y ago
Looking at his code, it's kind of scary. No comments. K&R C style declarations. Vast amounts of pointer arithmetic. What makes this work is that he defines a generic collection class.[1] This being C, it's a macro which generates a struct: #define GEN_ALLOC_typedef(ta,type,field,len,a) \ typedef struct ta { type *field; unsigned int len;\ unsigned int a; } ta; This is equivalent to <vector> from C++. Then he defines strings based on this (see stralloc.h), and provides the usual operations on them. Disciplined use of those primitives provides good reliability for all the string handling a mail handler does. [1] https://github.com/amery/qmail/blob/master/gen_alloc.h https://github.com/amery/qmail/blob/master/gen_alloc.h
- oblio 12y ago
  So basically, Pascal strings? :)
  - acqq 12y ago
    No, basically, generics, like the STL in C++, but in plain C using just macros.
- BrandonM 12y ago
  > Looking at his code, it's kind of scary. No comments. Did you ckeck out addresses.5, for example? The source may not be commented, but if he clearly describes his assumptions (he does), source comments are less necessary. > K&R C style declarations. I don't understand what bearing this has on code quality. Do you contend that it leads to bugs?
  - acqq 12y ago
    And the code had to be compiled with the compilers that even in nineties were "old".
    - simtel20 12y ago
      I don't think you are right to say "had to be compiled with". It could be compiled with SunOS cc, and the c compilers of other vendors that were crappy and out-of-date. It could also be compiled on the current gcc/egcs etc. that were out. I think it had issues with e.g. the solaris cc because it was a pretty broken and barely used compiler to begin with.
rikkus 12y ago
I used to work as a UNIX admin, so having a home OpenBSD box to handle mail seemed like a requirement. I ran qmail and djbdns, under daemontools, because there was nothing else as secure, nothing else 'properly' designed (I agreed with the design principles behind the software) and nothing else as easy to administer (I really don't like m4). I spent a long time trying to understand why DJB's software wasn't considered the gold standard and installed by default on all Linuxes and BSDs. I read lots about arrogance, but couldn't see any - I could only see a commitment to solid software. Eventually the only theory I was left with was that perhaps the 'UNIX way' was something people didn't really understand, or didn't want to invest time into understanding. I'll draw a parallel with vi editor[s]: Those who invest time into understanding the vi philosophy are happy working with it and would rather not use anything else. Others think they (we - you might have guessed I'm a vi user) are somehow ultra geeky or hardcore. Maybe this is why there's a preference for server software with a shorter learning curve, too. The thing I really didn't 'get' was that to me, djb's tools had no learning curve, because they work 'the UNIX way'. Perhaps this is why those who like[d] his software never made their voice heard enough, or did the work, to get them into mainstream distributions: They don't understand why others don't see that they're great. There could be other reasons. For example: I gave up running my own mail server when I got sick of dealing with spam and couldn't find a decent web interface. I think squirrelmail was the best I could find at the time and gmail was so much better. Sorry, squirrelmail! Perhaps it was easier to integrate anti-spam software with other mail servers. Perhaps I never found out because I refused to use other mail servers, having seen all the security advisories. Maybe my refusal to consider 'insecure' software meant I was blind to the advantages of sendmail and postfix, rather than simply others being blind to the advantages of qmail.
- SixSigma 12y ago
  > I spent a long time trying to understand why DJB's software wasn't considered the gold standard and installed by default on all Linuxes and BSDs. His license had a "no modifications" clause, for one thing.
  - badpenny 12y ago
    That and the fact they decidedly don't work "the UNIX way".
zurn 12y ago
The "one bug was found" only goes for exploitable security vulnerabilities. There have been many other, less impactful bugs. This is still an an impressive archievement, especially because DJB chooses to juggle with chainsaws and write in C.
- lawnchair_larry 12y ago
  It isn't even true for that. There have been several security bugs, which he stubbornly refused to fix.
  - kragen 12y ago
    There was one potential security bug (Guninski’s find), which was probably not exploitable on any installation of qmail. I don’t think there have been any other security bugs found in qmail.
    - lawnchair_larry 12y ago
      Guninski had several, and there were working exploits for them. Nobody uses the OS to set process limits like djb claimed (nor should they), so it was exploitable on any installation of qmail.
      - kragen 12y ago
        I didn't know there were two. There don't seem to be several. This seems to be the best summary of the situation: http://www.jcb-sc.com/qmail/guninski.html http://www.jcb-sc.com/qmail/guninski.html Those two definitely aren't "exploitable on any installation of qmail", as you say; they aren't exploitable on any 32-bit installation of qmail, any ILP64 installation of qmail, any installation of qmail with a reasonable data size rlimit, or any installation of qmail on a machine with less than a couple of gigabytes of RAM and swap, if I understand Guninski's post. If you're running qmail processes without data size rlimits, you're vulnerable to resource-exhaustion denial-of-service attacks in any case. There are established guides to configuring qmail that tell you to set rlimits. Burley's page I linked above says he was running with rlimits before the bugs were found. I'm pretty sure that when I ran qmail, I didn't set rlimits, though. One of the two bugs is in an unprivileged process, but coupled with a local privilege escalation bug, should be sufficient for root. The other is in a process that already runs as root, although for POP, which was a thing I didn't run when I ran qmail.
deleted 12y ago
[deleted]
brotherr 12y ago
Are you people serious? His code is absolutely disgusting: uugh = constmap(&mapuser,x,i); if (!uugh) die_user(x,i); ++i; x += i; xlen -= i; i = byte_chr(x,xlen,':'); if (i == xlen) return; https://github.com/amery/qmail/blob/aa6bf9739209ca76f7f3af0feada5552723a622b/qmail-pw2u.c#L205-L207 https://github.com/amery/qmail/blob/aa6bf9739209ca76f7f3af0f... It's mostly bug-free because it scares bugs away. If I was a bug I wouldn't want to live in there.
- jevgeni 12y ago
  An eloquent, objective, and thoroughly researched opinion.
- cremno 12y ago
  What are your issues with it? That the variable names are not descriptive enough to be understood when the code is taken out of context? That the if-substatements aren't compound statements? The last line? What would you have done instead (back then)? Every statement on a new line makes it more difficult to understand it since it belongs together, a macro obscures the code and also has to be named, and a function only for this is (was) too expensive speed and memory wise.
  - viraptor 12y ago
    Not the gp, but I agree with him. I dislike everything you listed, but think that even with context it's unreadable. Context is hard to find too since this file has 3 lines of comments only. (For an enum equivalent) Also, I don't buy the "function too expensive" idea - that looks like a crazy micro optimization. If it was needed, I'd say it deserves a comment.
    - cremno 12y ago
      Disliking omitting braces or really short names is just a matter of taste (however both is classic C coding style), but you can easily find out what they store without comments or a longer name. I personally would have chosen l instead of x, which is a pointer to a character in the current read _l_ine (see L202). Can you tell me what comments you're expecting? qmail comes with a bunch of man pages (including ones for functions and they're well written). The file is called qmail-pw2u.c and there's qmail-pw2u(8). The function is called dosubuser, so let's look up subuser in it: > Extra addresses. Each line has the form > sub:user:pre: That gives us a pretty good idea about the purpose of the posted code (plus the previous lines). I agree, a function or macro makes sense (since there are many other equivalent constructs in the same file), but that's "just" giving a bunch of statement a name. Does field_next explain what they do? static int field_next(int *i, char **x, unsigned *xlen) { *++i; *x += *i; *xlen -= *i; *i = byte_chr(*x,*xlen,':'); return i == xlen; } / * later */ if (field_next(&i, &x, &xlen)) return; The rest of the function is writing something. Maybe we should find out the purpose of the program at first? The man page tells us this too: >qmail-pw2u reads a V7-format passwd file from standard input and prints a qmail-users-format assignment file.
PaulRobinson 12y ago
I don't hate djb, but I won't run his code. If you should happen to get involved in IETF discussions, I believe you will still occasionally find him there discussing how to fix various protocols. Back in 2002 I was witness/participant to one discussion involving djb that made me think twice. Because a great deal of software will not be able to handle Unicode (even now) there was some discussion back then about how to handle domain names in older software once domains with non-ASCII characters were allowed. If your software is assuming all ASCII characters, how do you display/handle a domain with greek or cyrillic characters? This obviously affects DNS and Mail software, so djb's contribution should have been valuable. The consensus from everybody else was a temporary hack: Punycode. http://en.wikipedia.org/wiki/Punycode http://en.wikipedia.org/wiki/Punycode djb did not like this. He suggested all software should instead represent the actual characters rather than changing them because humans should be able to read them. He proposed this should be done through ASCII art. So if you were to register ααα.com (that's three greek alphas if your browser can't render them), all software should display this as: _ /\/ /\/ /\/ / /\ /\/\ \/\ \/\ \/\ o \_ \/ | | We has very serious, and got very upset when we pointed out this would require re-writing all software deployed to date, and if we were going to do that we'd just make it support Unicode properly. My problem was that this idea was so batshit crazy I had to then question how crazy his actual implementations were. I dug into the source code of several of his tools. I came away feeling that the reason bugs had not been found in his code were not because his code was bug-free, but because it is impenetrable noise. As others have suggested here, it is uncommented, he uses a lot of pointer arithmetic, some parts don't make sense. Making a contribution to improve it is difficult. Identifying if the code is correct or not is near impossible. DJB's code might be bug free, but it is also quite likely to be bug-ridden but nobody has been brave or bored enough to figure out where those bugs are. I expect it does not have the same holes as BIND or sendmail (both of which are awful), but it will have holes. The wonderful beauty of open standards and the work that the IETF has done of course, is that it means we have choices and if you want to run djb's code, you can go and do that. If you don't - and I do not - you have choices of other software that will inter-operate with it as expected. I don't hate djb, but I don't trust the claims made about his code being watertight, and I do not believe somebody who writes code that is hard for others to understand is worthy of the title "greatest programmer who has ever lived". Good luck to him and all who use his code, but no thanks, not for me. P.S. - if you want to see what good code does look like in an MTA, take a glance at the source for exim one day. It is very clear and well structured, I think.
nisa 12y ago
A good time to link to the Unix Security Holes Course djb gave in 2004: http://cr.yp.to/2004-494.html http://cr.yp.to/2004-494.html
vermontdevil 12y ago
He also was the person behind Bernstein v United States which the Ninth Court ruled software as freedom of speech. http://en.wikipedia.org/wiki/Bernstein_v._United_States http://en.wikipedia.org/wiki/Bernstein_v._United_States
- talles 12y ago
  > Bernstein was originally represented by the Electronic Frontier Foundation, but he later represented himself despite having no formal training as a lawyer.
  - sarciszewski 12y ago
    Yes he did. He's sort of a badass like that.
deleted 12y ago
[deleted]
101914 12y ago
Personal opinion: the world needs more code generators like qhasm.
taeric 12y ago
I question the reasoning for calling Knuth's abilities into doubt because he had a diary of all of the bugs he encountered along the way in his programs. That is a practice of his that I often feel I should imitate.
- wglb 12y ago
  I did that on one project in previous lifetime. We had a paper journal that the team used, and I wrote down a description of each and every bug that I made. It improved my code substantially. I have restarted that task again.
justizin 12y ago
I largely agree with this, but I also think it's worth noting that DJB opted out of writing most functionality, leaving it to the end user, so he has provided us with a fantastic bike frame upon which we bolt far less superior software than the alternatives. You want AXFR with djbdns? Well, DJB decided that AXFR is stupid, and that you should live in a monoculture of only DJB software, which doesn't have to conform to standards, so you have to write scripts to handle this at both ends and AXFR is one of the BIGGEST security concerns in DNS. That said, I've really enjoyed running qmail, dnscache, and daemontools. These days I use runit, simply because it is maintained, because I have trouble buying into the notion that any software can be suitable across platforms and changing underlying libraries. I have no doubt that runit's code is less stringent than DJB's, and I find it fruastrating that a couple of things I used to do with daemontools cannot be done with runit. Anyway, always good to ressurect Aaron's ideas, that DJB outlasted him is a fucking shame.
- danudey 12y ago
  This is definitely true. qmail didn't have bugs in part because it implemented a barebones SMTP server, and had a lot of ridiculously onerous conditions under which it ran. For example, files in the queue were named after their inodes, meaning you couldn't just restore from backup and have it work. UID/GID were compiled in statically so you couldn't pre-build binaries and distribute them unless you had centralized user management via NIS/LDAP. There were no features and no way to extend functionality, meaning that as the internet's use of email changed (e.g. SPF records), everything was distributed as a patch to qmail. This meant 1. sysadmins got to spend more and more time applying patches that hadn't been tested together, struggling to even get them to apply or compile; 2. sysadmins got to debug a lot of other people's code because there wasn't anyone to report bugs to; 3. if you accidentally blew away your qmail build directory there wasn't much chance of you getting an identical configuration back again, making your entire mail system ridiculously fragile. When qmail was first released, it was awesome and amazing. Only a few years later, Postfix started providing the vast majority of the security benefits of qmail (e.g. separating privileges and functionality into separate daemons), with nowhere near the number of headaches. Need to change a configuration parameter? Just use postconf(1) instead of recompiling. Need to replicate your mail configuration? Just copy the configs over. Need to add new functionality? Milters. I worked at a hosting company a few years ago that still used qmail (and Apache 1.3, and this was in 2010); there was a slight misbehaviour in qmail which we needed to change, which resulted in one of our sysadmins (who didn't really know C) spending days reading, changing, compiling, testing, and debugging code which, with Postfix, would have been a one-line config change. And who knows if it's robust? He stopped working on it once he had a solution that passed his test without segfaulting immediately. Qmail did wonders for the internet by replacing sendmail, but horrors for the internet by replacing necessary functionality with onerous security, requiring third-party patches for almost everything other than just exchanging mail between servers, and refusing to update the code to add anything that wasn't there already.
jedberg 12y ago
DJB a software engineer who doesn't listen to other's input and believes that his way is always the right way. Despite the fact that his software is solid, I try to avoid it all costs because it is a huge pain to configure and manage and doesn't follow the UNIX way at all. It follows the DJB unix way, which is terrible if you want to use anything that isn't DJB. Also tinydns is fundamentally broken because DJB doesn't believe in split views.
- dsp 12y ago
  Are you aware of the client location (%lo) support introduced in 1.04? Since it works at a per-record level---instead of per-zone---I find it more useful than the typical split view support. http://cr.yp.to/djbdns/tinydns-data.html http://cr.yp.to/djbdns/tinydns-data.html
  - jedberg 12y ago
    I wasn't aware of that, and you're right, that is probably more useful than split view. So I stand corrected on that one point, but dang if it didn't take him a long time to come around.
- Canada 12y ago
  If anything, it's a huge pain to configure and manage because his software follows the Unix way more faithfully than most Unix server software: collections of small programs that communicate over well defined interfaces. As a programmer, it's great. The very minimal feature set and lack of high level abstractions makes the code very easy to understand and modify. The fact that everything uses stdio makes debugging really easy. As a sysadmin it sucks because providing the features your users rightly expect forces you to maintain patches as well as configuration. And a good deal of that configuration is long pipelines where tiny changes have huge consequences. Set the magic option in the magic variable to change behavior. Certain files that aren't explicitly mentioned anywhere just have to exist, and one wrong permission or file ownership just breaks everything and it's really annoying to figure out what's wrong.
  - 12y ago

271 points by cookrn 12y ago

qmail 1.03 source mirror on github: https://github.com/amery/qmail/tree/aa6bf9739209ca76f7f3af0feada5552723a622b https://github.com/amery/qmail/tree/aa6bf9739209ca76f7f3af0f...

stormbrew 12y ago
Which, in spite of its 'perfection', it should be noted that you should not run unpatched on a public facing server (or at least not qmail-smtpd), lest you become an unwitting backscatter zombie. I love djb's software, and I love his way of looking at things, but no software stays perfect forever.
- e12e 12y ago
  Had to look up what a backscatter zombie was; apparently it's what happens when you accept bogus mail (spam) into your mail queue without checking if it is actually deliverable -- thus end up bouncing it once the queue is processed for delivery -- and typically then sending it back to a forged address -- ie: you become a spam gateway (spammers send you email with sender-addresses they want you to try to send spam to...): http://serverfault.com/questions/111938/how-might-i-stop-backscatter-using-qmail http://serverfault.com/questions/111938/how-might-i-stop-bac...

jaryd 12y ago

I appreciate this as an avid user of daemontools (http://cr.yp.to/daemontools.html http://cr.yp.to/daemontools.html) -- thanks for the link!

geoka9 12y ago
Daemontools is a gift from the unix gods. Having been a unix user for most of my professional life, I haven't even heard of it until a project for which it was exactly what I needed. When I found it, within an hour I was ready to deploy with all my requirements met and the best of it - it all worked as any experienced unix user would expect it to be! (And I don't remember even skimming the man page.)

chrisdew 12y ago

Perhaps people are annoyed that DJB does everything his own way, rather than using standard tools? I vaguely remember building DJB's software from source to be non-trivial, but that was a decade ago.

deleted 12y ago
[deleted]

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

ohsnap 12y ago

DJB had some great comments on what he thought makes qmail secure: http://cr.yp.to/qmail/qmailsec-20071101.pdf http://cr.yp.to/qmail/qmailsec-20071101.pdf Perhaps the most legit complaint of DJB's work is that he would often lobotomize chunks of a protocol if he didn't like it. But it was still great work and it contrasted nicely to some horribly insecure software at that time (sendmail and bind)

cousin_it 12y ago
That's an amazing paper, thank you for linking to it! I actually learned something new from it, in particular the sections 5.1 "Accurately measuring the TCB" and 5.2 "Isolating single-source transformations". It turns out there's a wrong way and a right way to do "privilege minimization" for security, and all my life I've been thinking about it the wrong way.
- acqq 12y ago
  It also shows that the resulting "bug-minimal" code didn't just spring out of nothing but is the result of a lot of experience even two decades ago: "I started writing an MTA, qmail, in 1995, because I was sick of the security holes in Eric Allman’s “Sendmail” soft- ware." djb even then analysed the security aspects of the bugs. And spent the considerable time working on the solutions: "My views of security have become increasingly ruthless over the years. I see a huge amount of money and effort being invested in security, and I have become convinced that most of that money and effort is being wasted. Most “security” efforts are designed to stop yesterday’s attacks but fail completely to stop tomorrow’s attacks and are of no use in building invulnerable software. These efforts are a distraction from work that does have long-term value." BTW the "TCB" was never explained in the article but I guess he means "trusted computing base."

gitemacs 12y ago

I disagree with Aaron. I would reserve the title of the greatest programmer in the world to Fabrice Bellard. He single-handedly wrote QEMU, FFMPEG, an LTE base station, a PC emulator in javascript, and countless other projects. Alone. http://bellard.org/ http://bellard.org/

sanxiyn 12y ago
djb aims to write bug-free programs and actively works on improving the process to do so. While Bellard is a great programmer, I don't think Bellard aims to write bug-free programs. See section 8 of http://cr.yp.to/cv/activities-20050107.pdf http://cr.yp.to/cv/activities-20050107.pdf There are more people who aims to write bug-free programs, but most of them seem to use formal verification. djb seems pretty unique in aiming bug-free programs in normal programming and getting close. Re: Bellard software quality. Fuzzing found 1120 bugs in FFmpeg. While Bellard's code is only small part of entire FFmpeg, FFmpeg is very far from being bug-free. http://googleonlinesecurity.blogspot.com/2014/01/ffmpeg-and-thousand-fixes.html http://googleonlinesecurity.blogspot.com/2014/01/ffmpeg-and-...
- schoen 12y ago
  I was shocked (and impressed) when I looked at some of djb's code and saw that he put his "the return value of every syscall must be checked" view into practice so consistently that every single printf() (not only fprintf()!) was inside an if block that checked whether it succeeded in writing to stdout or not. Of course, printf() does have a return value ("Upon successful return, these functions return the number of characters printed"), and it can fail... but it takes a considerable consistency of purpose to decide to deal with that possibility explicitly every single time.
  - riffraff 12y ago
    out of curiosity, what do you (does he) do if printf fails?
    - svckr 12y ago

riffraff 12y ago

I have vague memories of the fact that qmail was mostly used with patches that DJB didn't want to incorporate, (e.g. support for STARTTLS). This ended up causing a lot of people to use other servers which _did_ respond to user demands. So maybe other than only learning from the way he writes code, we can also get some ideas on how to nurture open source projects.

pixl97 12y ago
DJB wasn't exactly wrong about TLS, it's been an unending source of security holes for a while now and everybody that's looking at the code expects more. Most of his work is actually dealing with encryption and pointing out flaws in implementations like DNSSEC (which provide no security to the end client).
MichaelGG 12y ago
There's also the licensing, preventing distros from using their own directory layouts. djb says they're being ridiculous and his folder layout is superior (and it is). But it seems to have the opposite effect if it just means packagers decide to simply drop the software :(
- tptacek 12y ago
  The software you're talking about is in the Public Domain.
  - raldi 12y ago
    Only since December 2007: http://en.wikipedia.org/wiki/Djbdns#Copyright_status http://en.wikipedia.org/wiki/Djbdns#Copyright_status http://en.wikipedia.org/wiki/Qmail#Copyright_status http://en.wikipedia.org/wiki/Qmail#Copyright_status The change was made because the situation was unfolding exactly as described above.

laurencerowe 12y ago

> But these programs are not just for being seen or read — like a graceful dancer, they move! This is what makes programming beautiful. The analogy that come most easily to me are to machines, like the wonderful stationary engines that sometimes ran at the Manchester Museum of Science and Industry. But in comparison their movement is so constrained... Dancing is far more representative.

agumonkey 12y ago
I had the same issue with college classes about software design compared to skycrapers. In my mind software has always been much more dynamic. I'll admit I like them too dynamic (lisp, meta, reactive, context oriented, AI). But even carefully constrained software is moving. Biology is also very fitting.

hippiefahrzeug 12y ago

I've followed a policy of using djb's software whenever possible over the years. Unfortunately qmail shows its age and may no longer be a good choice these days, but then again, who runs their own email server? :) daemontools and ucspi-tcp are still some of the best tools to dig into. I love multilog (part of daemontools) which solves problems I didn't even know exist. e.g. I had a pool of servers and wanted to collect all the logs in one place... the way multilog names files makes this a simple rsync task, and you can just concatenate and sort, it even works for multi-lined output. Since I started using docker, djb's tools got a new life for me. I manage all services within docker containers with daemontools.

davvid 12y ago
Unfortunately qmail shows its age and may no longer be a good choice these days Last I checked, Yahoo (Mail) uses qmail. Can anyone verify whether that is still true today?
- Arnt 12y ago
  Yahoo advertises TLS support, so the bulk of the code Yahoo uses will be third-party extensions, perhaps openssl.
vidarh 12y ago
Qmail may show its age, but the overall structure is sound, and one the beautiful parts of qmail was/is how it isolated everything in their own processes intercommunicating via very simple protocols over file descriptors. So you could build far more complicated mail systems by starting with qmail and replacing parts as you went. A company I co-founded used qmail for delivery for a webmail service for ~2m users, and while we used the original qmail less and less, it was because we were able to use qmail as scaffolding as described above. And we ran lots of services under daemontools. Later we used qmail as a generic message queueing system for a turnkey registrar platform for .name...
- voltagex_ 12y ago
  Are you able to expand on how qmail was used / not used? I didn't think it was something that could be easily modified like that

geofft 12y ago

The bug thing is about security holes, right? I think the comparison with Knuth is apples-to-oranges. Or is it actually the case that, since the first public releases of djbdns and qmail, no bugs, security or otherwise, have been found?

sanxiyn 12y ago
As I understand, there has been less than 10 or so non-security bugs each in djbdns and qmail, defined as programming mistakes, not intentional design decisions people disagree with. This is comparable to (or even better than) Knuth. I don't think there is a handy list of bugs though.
self 12y ago
There have been several non-security bugs. So far, I think there has been just one security bug in djbdns: http://securityandthe.net/2009/03/05/security-issue-in-djbdns-confirmed/ http://securityandthe.net/2009/03/05/security-issue-in-djbdn...

drinchev 12y ago

Wow three letters, so many stories in my head. Here are my top 5 reasons why I think qmail + daemontools + djbdns is great : 1. bugs free code ( well almost ) ; 2. fast & memory efficient ; 3. following "everything is a file" philosophy ; 4. easy to configure and more I've been using this suite for almost 10 years now. I've never found any alternative. BIND was too complicated in terms of configuration for me and also got updates almost every 2 weeks ( 8 years back it was much much harder than doing "apt-get ..." ) Qmail is also flawless piece of software. It basically taught me how you should separate processes and how to use linux accounts properly for the daemons. Amazing. Finally the only thing I rely on right now is daemontools. I'm using it for all of my production nodejs websites and even for a tool that I call "deployer" which automatically stops, updates and starts a daemon from the suite.

piranha 12y ago
Sorry, 8 years ago it was 2007 and updating BIND was done precisely by doing 'apt-get ...'. I still have a server running same installation of Debian since 2005 (copied from one HDD to another and to a virtual server then), and it's been apt-get updated all the way through.
- pixl97 12y ago
  I know you're having fun showing off how easy it was to update BIND, but how many times have you had to update it since that time? Now how many times did he have to update the DJB name server?
  - piranha 12y ago
    I don't know, I'm not counting them. And there is no doubt djbdns is better than BIND regarding security - it's just you can't use "8 years ago updating stuff was hard" as an argument, because it was not.
    - drinchev 12y ago
      8 years ago I was using slackware as my main server distribution. Yes there is no "apt-get ..." in slackware even nowadays, but back then debian switched to aptitude at around 2005 ( sarge ) [1]. I remember around 2010 I reached uptime 3 years on one of the machines, with my good old patched slackware 10. Now imagine me switching to "apt-get ..." because of "easy security updates" for a tool that lived less than my uptime was. Yes this is the time that I had to use exactly this argument, but against doing precisely that. 1: https://www.debian.org/doc/manuals/project-history/ch-detailed.en.html https://www.debian.org/doc/manuals/project-history/ch-detail...

joosters 12y ago

If only djb's programs would write human-readable log files...

drinchev 12y ago
If you are talking about the date, it's documented how to parse it : > cat current | tai64nlocal
- joosters 12y ago
  Yes, it's the damn date. It doesn't matter how well documented it is, once you have to apply a conversion to logfiles before they can be easily read, you lose all your existing workflow. It becomes a pain to use. I never understood djb's aversion to using human-readable dates in the log files. It's not a lot of effort for the computer to produce or to consume them, so we really should push the effort onto the computer, and not onto the user.
  - drinchev 12y ago
    Yeah djb's way suggest we use TAI time format, because it's more accurate. Anyway I haven't found this to be so big of a hassle for me. And it sounds really cool what it's doing : > The standard timestamp used in "the djb way" is TAI, for Temps Atomique Internationale. It is an absolute measure of elapsed time based on the decay of cesium atoms, where one day is equivalent to exactly 86,400 TAI seconds. > But the actual rotation of the Earth does not exactly conform to the TAI idea of time. In fact the Earth is slowing down a little bit, so that each physical day is minutely more than 86,400 TAI seconds. > Our human notion of time is based on this physical day length, and is represented by the UTC timeclock. The UTC timeclock is intended to represent a clock that points exactly 12:00 noon when the Sun is directly overhead on the solstice at 0 degrees longitude. http://thedjbway.b0llix.net/leapsecs_update.html http://thedjbway.b0llix.net/leapsecs_update.html
    - MichaelGG 12y ago
      Yes, leap seconds are an abomination and something that should only exist for odd use cases, like astronomers or something. Forcing UTC into all software and civil use is vile. Hopefully UTC will stop getting leap seconds, or we'll move to something like UTC with no further leap seconds.

Animats 12y ago

Looking at his code, it's kind of scary. No comments. K&R C style declarations. Vast amounts of pointer arithmetic. What makes this work is that he defines a generic collection class.[1] This being C, it's a macro which generates a struct: #define GEN_ALLOC_typedef(ta,type,field,len,a) \ typedef struct ta { type *field; unsigned int len;\ unsigned int a; } ta; This is equivalent to <vector> from C++. Then he defines strings based on this (see stralloc.h), and provides the usual operations on them. Disciplined use of those primitives provides good reliability for all the string handling a mail handler does. [1] https://github.com/amery/qmail/blob/master/gen_alloc.h https://github.com/amery/qmail/blob/master/gen_alloc.h

oblio 12y ago
So basically, Pascal strings? :)
- acqq 12y ago
  No, basically, generics, like the STL in C++, but in plain C using just macros.
BrandonM 12y ago
> Looking at his code, it's kind of scary. No comments. Did you ckeck out addresses.5, for example? The source may not be commented, but if he clearly describes his assumptions (he does), source comments are less necessary. > K&R C style declarations. I don't understand what bearing this has on code quality. Do you contend that it leads to bugs?
- acqq 12y ago
  And the code had to be compiled with the compilers that even in nineties were "old".
  - simtel20 12y ago
    I don't think you are right to say "had to be compiled with". It could be compiled with SunOS cc, and the c compilers of other vendors that were crappy and out-of-date. It could also be compiled on the current gcc/egcs etc. that were out. I think it had issues with e.g. the solaris cc because it was a pretty broken and barely used compiler to begin with.

rikkus 12y ago

I used to work as a UNIX admin, so having a home OpenBSD box to handle mail seemed like a requirement. I ran qmail and djbdns, under daemontools, because there was nothing else as secure, nothing else 'properly' designed (I agreed with the design principles behind the software) and nothing else as easy to administer (I really don't like m4). I spent a long time trying to understand why DJB's software wasn't considered the gold standard and installed by default on all Linuxes and BSDs. I read lots about arrogance, but couldn't see any - I could only see a commitment to solid software. Eventually the only theory I was left with was that perhaps the 'UNIX way' was something people didn't really understand, or didn't want to invest time into understanding. I'll draw a parallel with vi editor[s]: Those who invest time into understanding the vi philosophy are happy working with it and would rather not use anything else. Others think they (we - you might have guessed I'm a vi user) are somehow ultra geeky or hardcore. Maybe this is why there's a preference for server software with a shorter learning curve, too. The thing I really didn't 'get' was that to me, djb's tools had no learning curve, because they work 'the UNIX way'. Perhaps this is why those who like[d] his software never made their voice heard enough, or did the work, to get them into mainstream distributions: They don't understand why others don't see that they're great. There could be other reasons. For example: I gave up running my own mail server when I got sick of dealing with spam and couldn't find a decent web interface. I think squirrelmail was the best I could find at the time and gmail was so much better. Sorry, squirrelmail! Perhaps it was easier to integrate anti-spam software with other mail servers. Perhaps I never found out because I refused to use other mail servers, having seen all the security advisories. Maybe my refusal to consider 'insecure' software meant I was blind to the advantages of sendmail and postfix, rather than simply others being blind to the advantages of qmail.

SixSigma 12y ago
> I spent a long time trying to understand why DJB's software wasn't considered the gold standard and installed by default on all Linuxes and BSDs. His license had a "no modifications" clause, for one thing.
- badpenny 12y ago
  That and the fact they decidedly don't work "the UNIX way".

zurn 12y ago

The "one bug was found" only goes for exploitable security vulnerabilities. There have been many other, less impactful bugs. This is still an an impressive archievement, especially because DJB chooses to juggle with chainsaws and write in C.

lawnchair_larry 12y ago
It isn't even true for that. There have been several security bugs, which he stubbornly refused to fix.
- kragen 12y ago
  There was one potential security bug (Guninski’s find), which was probably not exploitable on any installation of qmail. I don’t think there have been any other security bugs found in qmail.
  - lawnchair_larry 12y ago
    Guninski had several, and there were working exploits for them. Nobody uses the OS to set process limits like djb claimed (nor should they), so it was exploitable on any installation of qmail.
    - kragen 12y ago
      I didn't know there were two. There don't seem to be several. This seems to be the best summary of the situation: http://www.jcb-sc.com/qmail/guninski.html http://www.jcb-sc.com/qmail/guninski.html Those two definitely aren't "exploitable on any installation of qmail", as you say; they aren't exploitable on any 32-bit installation of qmail, any ILP64 installation of qmail, any installation of qmail with a reasonable data size rlimit, or any installation of qmail on a machine with less than a couple of gigabytes of RAM and swap, if I understand Guninski's post. If you're running qmail processes without data size rlimits, you're vulnerable to resource-exhaustion denial-of-service attacks in any case. There are established guides to configuring qmail that tell you to set rlimits. Burley's page I linked above says he was running with rlimits before the bugs were found. I'm pretty sure that when I ran qmail, I didn't set rlimits, though. One of the two bugs is in an unprivileged process, but coupled with a local privilege escalation bug, should be sufficient for root. The other is in a process that already runs as root, although for POP, which was a thing I didn't run when I ran qmail.

deleted 12y ago

[deleted]

brotherr 12y ago

Are you people serious? His code is absolutely disgusting: uugh = constmap(&mapuser,x,i); if (!uugh) die_user(x,i); ++i; x += i; xlen -= i; i = byte_chr(x,xlen,':'); if (i == xlen) return; https://github.com/amery/qmail/blob/aa6bf9739209ca76f7f3af0feada5552723a622b/qmail-pw2u.c#L205-L207 https://github.com/amery/qmail/blob/aa6bf9739209ca76f7f3af0f... It's mostly bug-free because it scares bugs away. If I was a bug I wouldn't want to live in there.

jevgeni 12y ago
An eloquent, objective, and thoroughly researched opinion.
cremno 12y ago
What are your issues with it? That the variable names are not descriptive enough to be understood when the code is taken out of context? That the if-substatements aren't compound statements? The last line? What would you have done instead (back then)? Every statement on a new line makes it more difficult to understand it since it belongs together, a macro obscures the code and also has to be named, and a function only for this is (was) too expensive speed and memory wise.
- viraptor 12y ago
  Not the gp, but I agree with him. I dislike everything you listed, but think that even with context it's unreadable. Context is hard to find too since this file has 3 lines of comments only. (For an enum equivalent) Also, I don't buy the "function too expensive" idea - that looks like a crazy micro optimization. If it was needed, I'd say it deserves a comment.
  - cremno 12y ago
    Disliking omitting braces or really short names is just a matter of taste (however both is classic C coding style), but you can easily find out what they store without comments or a longer name. I personally would have chosen l instead of x, which is a pointer to a character in the current read _l_ine (see L202). Can you tell me what comments you're expecting? qmail comes with a bunch of man pages (including ones for functions and they're well written). The file is called qmail-pw2u.c and there's qmail-pw2u(8). The function is called dosubuser, so let's look up subuser in it: > Extra addresses. Each line has the form > sub:user:pre: That gives us a pretty good idea about the purpose of the posted code (plus the previous lines). I agree, a function or macro makes sense (since there are many other equivalent constructs in the same file), but that's "just" giving a bunch of statement a name. Does field_next explain what they do? static int field_next(int *i, char **x, unsigned *xlen) { *++i; *x += *i; *xlen -= *i; *i = byte_chr(*x,*xlen,':'); return i == xlen; } / * later */ if (field_next(&i, &x, &xlen)) return; The rest of the function is writing something. Maybe we should find out the purpose of the program at first? The man page tells us this too: >qmail-pw2u reads a V7-format passwd file from standard input and prints a qmail-users-format assignment file.

PaulRobinson 12y ago

I don't hate djb, but I won't run his code. If you should happen to get involved in IETF discussions, I believe you will still occasionally find him there discussing how to fix various protocols. Back in 2002 I was witness/participant to one discussion involving djb that made me think twice. Because a great deal of software will not be able to handle Unicode (even now) there was some discussion back then about how to handle domain names in older software once domains with non-ASCII characters were allowed. If your software is assuming all ASCII characters, how do you display/handle a domain with greek or cyrillic characters? This obviously affects DNS and Mail software, so djb's contribution should have been valuable. The consensus from everybody else was a temporary hack: Punycode. http://en.wikipedia.org/wiki/Punycode http://en.wikipedia.org/wiki/Punycode djb did not like this. He suggested all software should instead represent the actual characters rather than changing them because humans should be able to read them. He proposed this should be done through ASCII art. So if you were to register ααα.com (that's three greek alphas if your browser can't render them), all software should display this as: _ /\/ /\/ /\/ / /\ /\/\ \/\ \/\ \/\ o \_ \/ | | We has very serious, and got very upset when we pointed out this would require re-writing all software deployed to date, and if we were going to do that we'd just make it support Unicode properly. My problem was that this idea was so batshit crazy I had to then question how crazy his actual implementations were. I dug into the source code of several of his tools. I came away feeling that the reason bugs had not been found in his code were not because his code was bug-free, but because it is impenetrable noise. As others have suggested here, it is uncommented, he uses a lot of pointer arithmetic, some parts don't make sense. Making a contribution to improve it is difficult. Identifying if the code is correct or not is near impossible. DJB's code might be bug free, but it is also quite likely to be bug-ridden but nobody has been brave or bored enough to figure out where those bugs are. I expect it does not have the same holes as BIND or sendmail (both of which are awful), but it will have holes. The wonderful beauty of open standards and the work that the IETF has done of course, is that it means we have choices and if you want to run djb's code, you can go and do that. If you don't - and I do not - you have choices of other software that will inter-operate with it as expected. I don't hate djb, but I don't trust the claims made about his code being watertight, and I do not believe somebody who writes code that is hard for others to understand is worthy of the title "greatest programmer who has ever lived". Good luck to him and all who use his code, but no thanks, not for me. P.S. - if you want to see what good code does look like in an MTA, take a glance at the source for exim one day. It is very clear and well structured, I think.

nisa 12y ago

A good time to link to the Unix Security Holes Course djb gave in 2004: http://cr.yp.to/2004-494.html http://cr.yp.to/2004-494.html

vermontdevil 12y ago

He also was the person behind Bernstein v United States which the Ninth Court ruled software as freedom of speech. http://en.wikipedia.org/wiki/Bernstein_v._United_States http://en.wikipedia.org/wiki/Bernstein_v._United_States

talles 12y ago
> Bernstein was originally represented by the Electronic Frontier Foundation, but he later represented himself despite having no formal training as a lawyer.
- sarciszewski 12y ago
  Yes he did. He's sort of a badass like that.

deleted 12y ago

[deleted]

101914 12y ago

Personal opinion: the world needs more code generators like qhasm.

taeric 12y ago

I question the reasoning for calling Knuth's abilities into doubt because he had a diary of all of the bugs he encountered along the way in his programs. That is a practice of his that I often feel I should imitate.

wglb 12y ago
I did that on one project in previous lifetime. We had a paper journal that the team used, and I wrote down a description of each and every bug that I made. It improved my code substantially. I have restarted that task again.

justizin 12y ago

I largely agree with this, but I also think it's worth noting that DJB opted out of writing most functionality, leaving it to the end user, so he has provided us with a fantastic bike frame upon which we bolt far less superior software than the alternatives. You want AXFR with djbdns? Well, DJB decided that AXFR is stupid, and that you should live in a monoculture of only DJB software, which doesn't have to conform to standards, so you have to write scripts to handle this at both ends and AXFR is one of the BIGGEST security concerns in DNS. That said, I've really enjoyed running qmail, dnscache, and daemontools. These days I use runit, simply because it is maintained, because I have trouble buying into the notion that any software can be suitable across platforms and changing underlying libraries. I have no doubt that runit's code is less stringent than DJB's, and I find it fruastrating that a couple of things I used to do with daemontools cannot be done with runit. Anyway, always good to ressurect Aaron's ideas, that DJB outlasted him is a fucking shame.

danudey 12y ago
This is definitely true. qmail didn't have bugs in part because it implemented a barebones SMTP server, and had a lot of ridiculously onerous conditions under which it ran. For example, files in the queue were named after their inodes, meaning you couldn't just restore from backup and have it work. UID/GID were compiled in statically so you couldn't pre-build binaries and distribute them unless you had centralized user management via NIS/LDAP. There were no features and no way to extend functionality, meaning that as the internet's use of email changed (e.g. SPF records), everything was distributed as a patch to qmail. This meant 1. sysadmins got to spend more and more time applying patches that hadn't been tested together, struggling to even get them to apply or compile; 2. sysadmins got to debug a lot of other people's code because there wasn't anyone to report bugs to; 3. if you accidentally blew away your qmail build directory there wasn't much chance of you getting an identical configuration back again, making your entire mail system ridiculously fragile. When qmail was first released, it was awesome and amazing. Only a few years later, Postfix started providing the vast majority of the security benefits of qmail (e.g. separating privileges and functionality into separate daemons), with nowhere near the number of headaches. Need to change a configuration parameter? Just use postconf(1) instead of recompiling. Need to replicate your mail configuration? Just copy the configs over. Need to add new functionality? Milters. I worked at a hosting company a few years ago that still used qmail (and Apache 1.3, and this was in 2010); there was a slight misbehaviour in qmail which we needed to change, which resulted in one of our sysadmins (who didn't really know C) spending days reading, changing, compiling, testing, and debugging code which, with Postfix, would have been a one-line config change. And who knows if it's robust? He stopped working on it once he had a solution that passed his test without segfaulting immediately. Qmail did wonders for the internet by replacing sendmail, but horrors for the internet by replacing necessary functionality with onerous security, requiring third-party patches for almost everything other than just exchanging mail between servers, and refusing to update the code to add anything that wasn't there already.

jedberg 12y ago

DJB a software engineer who doesn't listen to other's input and believes that his way is always the right way. Despite the fact that his software is solid, I try to avoid it all costs because it is a huge pain to configure and manage and doesn't follow the UNIX way at all. It follows the DJB unix way, which is terrible if you want to use anything that isn't DJB. Also tinydns is fundamentally broken because DJB doesn't believe in split views.

dsp 12y ago
Are you aware of the client location (%lo) support introduced in 1.04? Since it works at a per-record level---instead of per-zone---I find it more useful than the typical split view support. http://cr.yp.to/djbdns/tinydns-data.html http://cr.yp.to/djbdns/tinydns-data.html
- jedberg 12y ago
  I wasn't aware of that, and you're right, that is probably more useful than split view. So I stand corrected on that one point, but dang if it didn't take him a long time to come around.
Canada 12y ago
If anything, it's a huge pain to configure and manage because his software follows the Unix way more faithfully than most Unix server software: collections of small programs that communicate over well defined interfaces. As a programmer, it's great. The very minimal feature set and lack of high level abstractions makes the code very easy to understand and modify. The fact that everything uses stdio makes debugging really easy. As a sysadmin it sucks because providing the features your users rightly expect forces you to maintain patches as well as configuration. And a good deal of that configuration is long pipelines where tiny changes have huge consequences. Set the magic option in the magic variable to change behavior. Certain files that aren't explicitly mentioned anywhere just have to exist, and one wrong permission or file ownership just breaks everything and it's really annoying to figure out what's wrong.
- 12y ago