8 ms·

The DJB Legacy (2011)

84 points by pmoriarty 4y ago

teunispeters 4y ago
After managing systems running his tools in the past (circa 1990s-2000s) I came to the sad realisation that a lot of the "security" for qmail in particular was "deny that certain circumstances were happening" - as in do not log, do not report, leave as little trace as possible when a server was hijacked by spammers. 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.
ReactiveJelly 4y ago
- vore 4y ago
  No, that's jwz.
no-dr-onboard 4y ago
Honestly, DJB was an idol to me early on (maybe too strong of a word) as a security guy. His devotion to minimalism, concision, first concepts and utility are timeless principles that I’ve held throughout my career. Runit, tinydns and dnscache are bulletproof, purpose driven programs that have stood the test of time. Long live DJB.
- SockPuppy53 4y ago
  > dnscache are bulletproof 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 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".
  - no-dr-onboard 4y ago
    No shade taken. Your assessment makes sense if you look at it from a “how does it do today” standpoint. 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.
  - Woodi 4y ago
    >> Runit, tinydns and dnscache are bulletproof > dnscache are bulletproof 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 ? :>
- cromd 4y ago
  If I’m not mistaken, runit was another author. Did you maybe mean daemontools? (Agree with the general sentiment though, and both tools felt nice to use.)
daniel-cussen 4y ago
Solid algorithmist.
howinteresting 4y ago
rconti 4y ago
What's the supposed principle behind logging IPs and time in hex in tinydns? It always just felt like a colossal, pedantic pain in the ass, but I can't even really be sure it's pedantic without knowing it's better in some way, real or imagined.
- lifthrasiir 4y ago
  Timestamp parsing is a surprisingly taxing task for handling a large log file. Skalib documentation also mentions a difficulty [1]. [1] https://skarnet.org/software/skalibs/libstddjb/tai.html#timestamp 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."
  - skissane 4y ago
    > use TAI64N timestamps instead 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.
    - lifthrasiir 4y ago
      I think that they operate on the assumption that the system zoneinfo is "right" and contains leap second information by itself (and "right" is not a pun, tzdata does provide Right/* zones that exactly do this!). And I agree to you; this is a very fragile assumption even when you have a total control over the system.
tmountain 4y ago
He’s only 50. Is it a little early to talk about his legacy? Meaning, have we reached the end of his contributions?
- ratsmack 4y ago
  A legacy can be a work in progress.
- SAI_Peregrinus 4y ago
  He's still quite active in the academic cryptography sphere. Much of his time recently has clearly been taken up by the NIST post-quantum cryptography contest, but he's also active on LKML.
  - 0des 4y ago
    He was also still presenting before covid.
deltasepsilon 4y ago
Why did MinimaLT [1] fizzle into nothingness? I was always interested in its attempt at an anti-DoS feature and wondered why something later like QUIC didn't have associated ideas. [1] https://cr.yp.to/tcpip/minimalt-20130522.pdf https://cr.yp.to/tcpip/minimalt-20130522.pdf
- habitue 4y ago
  I don't have specific knowledge of why it fizzled, but my default guess is that the authors wrote the paper up as a proposal, but then didn't follow up with years of doggedly promoting it in a way that would get it standardized or widely implemented
gerdesj 4y ago
I used to run Qmail back in the day for quite a few domains. It never failed, ever. I followed "Life with Qmail" and that worked rather well. 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.
- pengaru 4y ago
  I dunno man, exim has had some pretty nasty CVEs in recent years. https://www.opencve.io/cve?vendor=exim https://www.opencve.io/cve?vendor=exim
  - tptacek 4y ago
    Exim's reputation is baffling to me. It's a first-generation (C-language, memory-unsafe, fully-privileged, libc-backed) MTA based on SMail. It's always been about as resilient as you'd expect given that pedigree. And yet, somehow, over the last 15 years it's been perceived as a secure mailer, like qmail and Postfix (second-generation privilege-separated security-first designs).
    - gjvc 4y ago
      Yes, agree 100x. Never understood its popularity. I expect once people had migrated away from sendmail and m4 to something sane they were not minded to make another MTA migration again any time soon after that :-) (cue responses about sendmail.mc not being all that bad...)DNL
    - pengaru 4y ago
      Same, and I've never understood why Debian installs insist on pulling exim into my life. 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.
smitty1e 4y ago
Seems very much alive, despite the dated feel of the reference => https://en.m.wikipedia.org/wiki/Daniel_J._Bernstein https://en.m.wikipedia.org/wiki/Daniel_J._Bernstein
dang 4y ago
Related: The DJB legacy - https://news.ycombinator.com/item?id=12600792 https://news.ycombinator.com/item?id=12600792 - Sept 2016 (9 comments)
rabite 4y ago
- gjvc 4y ago
tptacek 4y ago
This article has not really all that much to do with Daniel Bernstein's legacy, which almost certainly won't have much to do with qmail, djbdns, and daemontools --- none of these are tools you're likely to pick up anymore, and that's for the good; they were important in their time but also an evolutionary dead end. 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.
- sillysaurusx 4y ago
  > 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. 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.
  - inopinatus 4y ago
    It’s notoriously cryptic, undercommented, and heavy on idiosyncracies, particularly the macros. 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.
    - 4y ago
helpfulclippy 4y ago
It’s also worth noting that in grad school, DJB litigated the USG’s classification of cryptography as a munition. This led to the court finding that code is speech, and protected by the first amendment.
nickcw 4y ago
I'll be forever grateful to djb for djbdns. 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!
0des 4y ago
Good grief the amount of pessimistic ignorance in this thread about someone who is quite literally devoting his life to our safe future.

84 points by pmoriarty 4y ago

After managing systems running his tools in the past (circa 1990s-2000s) I came to the sad realisation that a lot of the "security" for qmail in particular was "deny that certain circumstances were happening" - as in do not log, do not report, leave as little trace as possible when a server was hijacked by spammers. 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.

ReactiveJelly 4y ago

vore 4y ago
No, that's jwz.

no-dr-onboard 4y ago

Honestly, DJB was an idol to me early on (maybe too strong of a word) as a security guy. His devotion to minimalism, concision, first concepts and utility are timeless principles that I’ve held throughout my career. Runit, tinydns and dnscache are bulletproof, purpose driven programs that have stood the test of time. Long live DJB.

SockPuppy53 4y ago
> dnscache are bulletproof 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 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".
- no-dr-onboard 4y ago
  No shade taken. Your assessment makes sense if you look at it from a “how does it do today” standpoint. 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.
- Woodi 4y ago
  >> Runit, tinydns and dnscache are bulletproof > dnscache are bulletproof 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 ? :>
cromd 4y ago
If I’m not mistaken, runit was another author. Did you maybe mean daemontools? (Agree with the general sentiment though, and both tools felt nice to use.)

daniel-cussen 4y ago

Solid algorithmist.

howinteresting 4y ago

rconti 4y ago

What's the supposed principle behind logging IPs and time in hex in tinydns? It always just felt like a colossal, pedantic pain in the ass, but I can't even really be sure it's pedantic without knowing it's better in some way, real or imagined.

lifthrasiir 4y ago
Timestamp parsing is a surprisingly taxing task for handling a large log file. Skalib documentation also mentions a difficulty [1]. [1] https://skarnet.org/software/skalibs/libstddjb/tai.html#timestamp 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."
- skissane 4y ago
  > use TAI64N timestamps instead 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.
  - lifthrasiir 4y ago
    I think that they operate on the assumption that the system zoneinfo is "right" and contains leap second information by itself (and "right" is not a pun, tzdata does provide Right/* zones that exactly do this!). And I agree to you; this is a very fragile assumption even when you have a total control over the system.

tmountain 4y ago

He’s only 50. Is it a little early to talk about his legacy? Meaning, have we reached the end of his contributions?

ratsmack 4y ago
A legacy can be a work in progress.
SAI_Peregrinus 4y ago
He's still quite active in the academic cryptography sphere. Much of his time recently has clearly been taken up by the NIST post-quantum cryptography contest, but he's also active on LKML.
- 0des 4y ago
  He was also still presenting before covid.

deltasepsilon 4y ago

Why did MinimaLT [1] fizzle into nothingness? I was always interested in its attempt at an anti-DoS feature and wondered why something later like QUIC didn't have associated ideas. [1] https://cr.yp.to/tcpip/minimalt-20130522.pdf https://cr.yp.to/tcpip/minimalt-20130522.pdf

habitue 4y ago
I don't have specific knowledge of why it fizzled, but my default guess is that the authors wrote the paper up as a proposal, but then didn't follow up with years of doggedly promoting it in a way that would get it standardized or widely implemented

gerdesj 4y ago

I used to run Qmail back in the day for quite a few domains. It never failed, ever. I followed "Life with Qmail" and that worked rather well. 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.

pengaru 4y ago
I dunno man, exim has had some pretty nasty CVEs in recent years. https://www.opencve.io/cve?vendor=exim https://www.opencve.io/cve?vendor=exim
- tptacek 4y ago
  Exim's reputation is baffling to me. It's a first-generation (C-language, memory-unsafe, fully-privileged, libc-backed) MTA based on SMail. It's always been about as resilient as you'd expect given that pedigree. And yet, somehow, over the last 15 years it's been perceived as a secure mailer, like qmail and Postfix (second-generation privilege-separated security-first designs).
  - gjvc 4y ago
    Yes, agree 100x. Never understood its popularity. I expect once people had migrated away from sendmail and m4 to something sane they were not minded to make another MTA migration again any time soon after that :-) (cue responses about sendmail.mc not being all that bad...)DNL
  - pengaru 4y ago
    Same, and I've never understood why Debian installs insist on pulling exim into my life. 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.

smitty1e 4y ago

Seems very much alive, despite the dated feel of the reference => https://en.m.wikipedia.org/wiki/Daniel_J._Bernstein https://en.m.wikipedia.org/wiki/Daniel_J._Bernstein

dang 4y ago

Related: The DJB legacy - https://news.ycombinator.com/item?id=12600792 https://news.ycombinator.com/item?id=12600792 - Sept 2016 (9 comments)

rabite 4y ago

gjvc 4y ago

tptacek 4y ago

This article has not really all that much to do with Daniel Bernstein's legacy, which almost certainly won't have much to do with qmail, djbdns, and daemontools --- none of these are tools you're likely to pick up anymore, and that's for the good; they were important in their time but also an evolutionary dead end. 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.

sillysaurusx 4y ago
> 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. 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.
- inopinatus 4y ago
  It’s notoriously cryptic, undercommented, and heavy on idiosyncracies, particularly the macros. 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.
  - 4y ago

helpfulclippy 4y ago

It’s also worth noting that in grad school, DJB litigated the USG’s classification of cryptography as a munition. This led to the court finding that code is speech, and protected by the first amendment.

nickcw 4y ago

I'll be forever grateful to djb for djbdns. 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!

0des 4y ago

Good grief the amount of pessimistic ignorance in this thread about someone who is quite literally devoting his life to our safe future.