See section 8 of 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-...
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.
Last sentence in the paper:
"I won't be satisfied until I've put the entire security industry out of work."
That's nothing short of amazing.
Bellard is what you use on your laptop to have fun, DJB is what you run in your bank to make the world go round.
I spent quite some months learning about editors and one of my evening distractions was to write a new UI backend for qemacs. I found the design clever, quite flexible, etc, but in no-way easy to read or elegant. (To be fair, it did not help that he added a video player and a WYSIWYG html editor to it).
Later I came to a Vim clone called vis (https://github.com/martanne/vis) and I found the source code more close to those programs where you think "It can't be made simpler".
I wish future programmers read more code before writing just like literature writers do. It should be part of the education system and I regret not having read "classics" before starting writing.
(It won, of course. http://bellard.org/otcc/)
Fabrice Bellard is smart, though his code is hard to read imo.
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://en.wikipedia.org/wiki/Daemontools
not this Daemon Tools:
For a while, his stuff had weird licensing:
"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")
dtline += "\n"
Contrast this with the explicit error handling promoted by Go (and used in djb's software due to lack of exception handling in C).
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?
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
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 \_ \/ | |
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.
1: http://www.ietf.org/mail-archive/web/ietf/current/msg21058.h...
|
/\/ /\ | /^ /\ /\ /\
\/\ \/ | * \_ \/ | | |
http://www.cvedetails.com/vulnerability-list/vendor_id-10919...
http://www.cvedetails.com/vulnerability-list/vendor_id-86/Da...
Could there perhaps be some other interpretation of his stance in that debate? For example, maybe it was an elaborate joke about the SNAFU that is maintaining compatibility between ASCII and Unicode?
I think parent is very much misrepresenting djb's position. The ASCII art was a (off-hand) suggestion to display UTF-8 domains in a VT-100, not a general implementation.
Full of bugs, 2 code execution bugs last year. www.cvedetails.com/product/19563/Exim-Exim.html?vendor_id=10919
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.
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...
Last I checked, Yahoo (Mail) uses qmail. Can anyone verify whether that is still true today?
Anyone who cares about privacy? :)
Qmail is too old to be usable these days, but Postfix does at least use its security model. It isn't perfect, but arguably the best mail server around for that reason.
Hilary Clinton
With regard to age, both qmail and Postfix were written around 1998.
For my purposes, qmail works just fine. I use it; therefore it is "useable".
For me, Postfix is overkill. Not fact, just my opinion. Personal preference.
In the event I want to change something, I find it easier to modify and recompile qmail than I do to modify and recompile Postfix.
#define GEN_ALLOC_typedef(ta,type,field,len,a) \
typedef struct ta { type *field; unsigned int len;\
unsigned int a; } ta;
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?
This is not a defense of the code as I have not had a chance to look at it. It seems like Swartz was a bit over the top in his description of its greatness and I am naturally skeptical of such idolatry.
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
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.
As much as DJB is a talented programmer, his attitude towards outside contributions comes across as extremely hostile.
I can't take any of the DJB projects seriously because they're always in a state of permanent abandonment and maintainers are impossible to find. They serve as art pieces more than practical, useful software.
He's certainly from the old school of development where tight control over your software ensures it's not exposed to risk from external developers, and of course he's entitled to do that. The consequence is that severely limits how this software can be used.
"I can't take any of the DJB projects seriously because they're always in a state of permanent abandonment and maintainers are impossible to find. They serve as art pieces more than practical, useful software."
There are plenty of "maintainers", just search for the qmail mailing list, if that is impossible then I'm not sure what to say to you, but what you say is bunk.
Most of your other statements seem similarly at odds with reality to me, but they’re more statements of your taste than anything else.
The rest of the qualities do stand. We kept tinydns from that evaluation, and gladly so. It's a marvelous piece of software, never breaks on its own, requires near zero maintenance.
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;
It's mostly bug-free because it scares bugs away. If I was a bug I wouldn't want to live in there.
It's a question of priorities, seems like djb prioritizes correctness over readability - which is fine, but does limit the size of his audience.
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.
His license had a "no modifications" clause, for one thing.
Their suggestion was to just back everything up and reinstall. Sometimes that would fix it.
I spent the next 2 days meticulously setting up my RHL/Qmail server and never had an issue. Ran like a champ until that startup died.
Also tinydns is fundamentally broken because DJB doesn't believe in split views.
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.
In my worldview, that's only part of the unix way. The other part is putting the files in well known and agreed upon locations, like /usr and /usr/local and /etc. DJB software breaks these conventions.
Everything else you said is spot on.
> cat current | tai64nlocal
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.
In many cases, I exec logger(1) instead as my log sink, which will emit logs to syslog, or a homegrown replacement that can handle lines longer than 8192 bytes.
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.
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.
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.
Anecdotal, please provide a link to the qmail mailing list with evidence.
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)
"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."
Or is it actually the case that, since the first public releases of djbdns and qmail, no bugs, security or otherwise, have been found?
I don't think there is a handy list of bugs though.
https://github.com/amery/qmail/tree/aa6bf9739209ca76f7f3af0f...
I love djb's software, and I love his way of looking at things, but no software stays perfect forever.
http://serverfault.com/questions/111938/how-might-i-stop-bac...
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.
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.)