The DJB Legacy (2011)
skarnet.org
skarnet.org
What I've learned from 27 years of working in subfields where Bernstein is prominent is that there are elements of his reputation that are probably well-earned. I used to believe (with, I think, good reason) that people who had viscerally negative opinions of him were betraying something important (and bad) about themselves. That might have been true at the time (call it '96-'06). It's less true now.
Regardless: Bernstein is important because of Curve25519, Ed25519 and ChaPoly. And those are huge contributions, and more or less not up for debate, unlike his C code.
I still think his way of organizing configuration files on the filesystem, the modularity of qmail and the elegance of daemontools are unsurpassed. You feel that you understand what is going on, and it isn't a chore to work with the software.
He didn't have time to form a "community" of contributors, and most contributors would have ruined the software anyway. He didn't work for $BIGCORP that would have foisted the software on everyone.
In reality, most OSS we use is because of marketing efforts of a "community" or a corporation (there are exceptions like the Linux kernel or gcc).
So… what do you dislike about his C code? It would be interesting to hear what a viscerally negative but correct opinion about code would look like.
It’s certainly difficult to write C well. But it’s hard to imagine you saying something like that about cperciva’s. Did djb do something to earn it?
I have basically no experience with his code, but it sounds like you could teach readers something about what you’ve seen.
Nevertheless you can learn a lot from deciphering djb’s source, particularly with regards to defensive programming, so don’t be afraid to dive in. Just recognise it wasn’t necessarily engineered for ease of collaboration. Once you get a feel for the internal structures you may be surprised how clearly you can reason about it.
Perhaps it’s a matter of taste but I always preferred working on Wietse Venema and Timo Sirainen’s code.
https://groups.google.com/a/list.nist.gov/group/pqc-forum/at...
Long live DJB.
If you run dnscache on the tubes, a PSA: one should apply patches to suppress duplicate outbound queries, which DJB's original code did not perform. This made dnscache vulnerable to birthday paradox attacks. Details: http://www.your.org/dnscache/djbdns.pdf
Also, you should apply patches to increase MAXUDP queue size to 1024 or much more for modern "web2.0" query demands, and to prevent induced flush attacks. Your distro might or might not do this patching (usually just IPv6 support), depending on the port maintainer's chosen balance between helpfulness and code purity. This issue seems oddly pronounced in dnscache port commit logs, compared to others ports, so you are advised to check what patches the maintainer thought were cool, and which were just for haters.
DJB's response was to abandon dnscache, saying the protocol was flawed. While Curve25519-based solutions offer a new approach to DNS (one oblivious to e2e DNSSEC applications), many users just run legacy dnscache based largely on its enduring reputation.
This is not shade, just a clinical statement: Stock dnscache must be patched to be more secure than stock BIND wrt duplicate queries; your distro may vary. That's simply a factual statement, not an attack on DJB, or anyone who likes DJB and/or his code. As the kids say, "fight me".
So, with 2 - 5 patches all that projects are still production ready ?
In other words: pls imagine git repo with such djb-originated project... So, such repo with ~5 commits (since ~1997) is current state of the art ?
And if there are some bugs there they certainly are in NSA secret-bugs collection ? :>
I don’t really see too much worth in it though. Of course requirements change and people make useful commits to the code. That’s to be found in any lasting open source project.
In a strange way, I find that your comment almost amplifies what I’m trying to say. Perhaps I wasn’t too clear, mea culpa.
I've moved on somewhat - I generally run Exim with rspamd for first touch SMTP these days. However I would say that I took on board a lot of attitude from Qmail and DJB.
Thank you Dan for being a complete and utter outspoken, opinionated and knowledgeable knobend. We need rather more of you and less of the usual twitterers and navel gazers.
I used to use qmail for ages. Actually, one of my first paid dev jobs was as a contractor for a small company that supported qmail/vpopmail back in the shared hosting heydays.
Lately I just run postfix in a container and hope for the best. qmail just became too obscure and borderline abandoned, and I got tired of having to constantly patch it for modern features. It was starting to feel again like running Apache+SSL before SSL was an actual supported feature; almost certainly full of exploitable bugs introduced by hacked-in modernities.
I don't have exim on my system, and I don't think I uninstalled it manually, how did you get exim on yours?
"Exim generally comes with default Debian installation" [0]
"Keep Exim as default" [1]
"Exim is the MTA (Mail Transfer Agent) installed by default on new debian installations" [2]
[0] https://wiki.debian.org/Exim
[1] https://wiki.debian.org/Debate/DefaultMTA
[2] https://wiki.debian.org/PkgExim4(cue responses about sendmail.mc not being all that bad...)DNL
But however better Exim's UX might be, it's important to understand that it's a first-generation MTA design. The second generation of MTAs happened specifically to address the security calamity that the first generation architecture caused: minimal privileges and fine-grained privilege separation, root-and-branch replacement of both standard C library functions and of standard C idioms that create memory corruption flaws, and, probably most importantly, a design that has security as an objective, informed by (well, what was in ~1996) the best understanding we had of secure programming.
The second generation was not entirely successful; in 2022 (and, for that matter, 2012), it essentially makes no sense to run a memory-unsafe MTA; memory-safe userland programs written in popular, general-purpose languages have no trouble keeping up with workloads much more stringent than SMTP.
(If you're curious, I'd say that memory-safe languages and database backends --- keeping individual messages off the filesystem --- defined the third and subsequent generations).
But Postfix and qmail were a giant step forward from Sendmail and SMail; like, there's just no comparison. So far as I can see, Exim did not take that step; it's hard to see how it could, because Exim did not start with a security-first design (you can find comp.security.unix threads from back in the day that discuss this in more detail).
I ran into a configuration issue with exim in the last few months that prevented me from receiving some email from Amazon SES. The logged error told me at what logical step in the process it happened, and contained a user-configured error message on that specific step, which allowed me to quickly find and update it. That's something I never got from Postfix.
Postfix's configuration is a completely flat mapping on a fixed pipeline, where that pipeline is not properly exposed to the user, and the documentation is not well-ordered outside a handful of quick tutorials - postconf.5 lays out the options in alphabetical order, not according to what part of the pipeline the options affect.
I'm also not sure what UX means either in this context - its an MTA.
I'll take your comment on the quality of the code as stated - I respect your judgement on that but bear in mind that Exim is continuously developed. I lurk on their mailing lists and Jeremy and Co are continuously refining it.
It is a single binary and that single binary is written in C but whenever CVEs come up, they seem to be handled with professionalism and alacrity. So, perhaps you might like to give it another go.
It is rather powerful in what you can do with it. For example you can update exim.conf and then run exim -bhc w.x.y.z and run through a SMTP session to test it as though you are coming from the IP address w.x.y.z.
Anyway, I suspect I have way worse binaries from a purist's perspective doing stuff on my systems than Exim. However, I do know I've shifted many, many millions and perhaps billions of emails with it without any snags.
Nobody I'm aware of has formalized the "generations" of MTAs, but they clearly exist.
There may have been a generation preceding them, but SMail and Sendmail are the first generation: highly featureful, no security design (they were often designed to simply shell out to pipelines to get things done!), with C foundations written --- I know this is hard for people in 2022 to grok --- before there was any common understanding of memory safety, not even overflows, let alone memory lifecycle issues like UAF. People forget that the first published stack overflow exploit (after the idiosyncratic Morris Worm) wasn't until 1995.
The next generation --- I'll call it the "second" generation --- improved both the performance (which was abysmal) and the security of the first; security was the motivation for them. qmail and Postfix are the big two designs here, and they share a bunch of architectural features.
And, my claim is, for like the last 10-15 years, nobody sane would have implemented an MTA in a memory-unsafe language (there's just no need), nor would they have used Unix Programming 101 techniques for storing data.
The UX of an MTA refers to how it's configured. As I wrote it, I thought maybe people would get hung up on that; after all, we'd refer to the "DX" of a development platform, so maybe I want to say "AX" for "admin experience". But then I thought, nah, that's silly.
The point of modern secure software designs is not to have the CVEs in the first place. Your operating assumption needs to be that your adversary knows about the "CVE" before you do.
In the early 2000s in the dot com boom I was CTO for a domain registration and hosting company.
We had millions of DNS records to host and at the time we were using bind. It used to take 45 minutes to reload on the fastest machines we could get with rocket class SCSI disks and the servers used to run with a massive load average.
Eventually I discovered djbdns which was great on so many fronts. It had a nice single file text format which was very easy to build from the database. That file was digested into a read only database which djbdns served directly, and best of all you could swap databases with zero downtime.
This turned reloading the nameservers into something which would run in a few seconds and the DNS servers then ran with minimal load.
You'd make different choices today most likely, but it really saved our bacon back then!
The DJB legacy - https://news.ycombinator.com/item?id=12600792 - Sept 2016 (9 comments)
[1] https://skarnet.org/software/skalibs/libstddjb/tai.html#time... "Please do not embed human-readable dates in your log files, thus making parsing tools unnecessarily hard to write; use TAI64N timestamps instead, design tools that can parse them, and translate them to human-readable form at human analysis time."
TAI rather than UTC is an uncommon choice. I can see some argument for it. But in practice, it is made difficult by the fact that many popular operating systems and language runtimes don’t have any built-in APIs for UTC-TAI inter-conversion, or leap-second table access.
Spammers sure didn't have a problem using it. Following SMTP spec as closely as qmail did made it really easy to be a spam redirector, sadly, and very very hard to secure. And pretty much no protection at all for clients, regardless of how many viruses were present in the mail itself.
I usually switched to postfix as it was low grief switch (good support for the same file layouts) - and much easier to harden. (I did use sendmail for a while - it's doable, just time consuming to work with. postfix was also a happier switch there). I never did find an alternative worth anything and have since retired from running email at all, instead paying for third party hosting.