The DJB Legacy (2011)(skarnet.org)
skarnet.org
The DJB Legacy (2011)
https://skarnet.org/software/skalibs/djblegacy.html
16 comments
He stopped working on the software, but certainly daemontools could have been systemd, qmail could have been the dominant mailer etc. if he had continued.
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).
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).
FWIW, the spirit of daemontools lives on in the s6 project.
https://skarnet.org/software/s6/
https://skarnet.org/software/s6/
> 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.
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.
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.
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.
Indeed, and Venema's Postfix was a huge win for sysadmins at the time who were sick of sendmail and didn't like the "half required batteries included" approach of qmail, eg. dealing with spotty support for Maildir in other software.
Uet Maildir + indexes is used now by almost every imap implementation.
I think it's important to realize that djb's code is an artifact of the era when it was written -- the 1990s, before C99 existed. A lot of his code would be far more readable if "translated" to use types and standard library functions which exist in modern C but didn't exist at the time.
I don’t have a strong opinion about it. I have held varying opinions over the years, but my take now is that outside of the kernel, I’m over C, much as I still enjoy writing it.
Also, a fair amount of macros to make it build on different platforms with varying endianess, alignment needs, differently named syscalls/functions, and so on.
[deleted]
People dislike the style. However if style actually mattered in terms of the whether or not the code is useful, then no one would be using his cryptography contributions, let alone calling them his only "important" contribution, because the cryptography was written in the same style as the programs he wrote in the 1990s. (Bias: I still use them everyday.)
[deleted]
Bernstein is still important and relevant today. He is part of the movement that is actively attempting to address quantum.
You mean with the formal complaint to NIST?
https://groups.google.com/a/list.nist.gov/group/pqc-forum/at...
https://groups.google.com/a/list.nist.gov/group/pqc-forum/at...
I'm hearing he is mostly piggy backing on others work, as from what I'm told he was a quantum skeptic and joined the game late (honestly just repeating informal chats with some people interested in that topic)
I'm not sure how that could be the case. Dan was among the first to push the notion of post-quantum cryptography, along with Johannes Buchmann and his research group at Darmstadt (which credit him in [1] with the coining of the notion of "post-quantum cryptography"). Both organized the first PQCrypto conference in 2006, and edited the first book on post-quantum crypto.
[1] https://eprint.iacr.org/2004/297
[1] https://eprint.iacr.org/2004/297
Isn't all science "piggy backing on others work"?
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.
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.
Long live DJB.
> 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
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".
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".
>> 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 ? :>
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 ? :>
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.
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.
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.)
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.
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 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
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).
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.
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.
> Same, and I've never understood why Debian installs insist on pulling exim into my life.
I don't have exim on my system, and I don't think I uninstalled it manually, how did you get exim on yours?
I don't have exim on my system, and I don't think I uninstalled it manually, how did you get exim on yours?
> 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]
"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/PkgExim4Yes, 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
(cue responses about sendmail.mc not being all that bad...)DNL
It's also /well/ clearer as an admin than configuring Postfix, which seems to have random options which do random things in multiple logical places. From an outside perspective, Postfix is a "big ball of muck", while configuring exim involves defining logical pipelines.
I don't know anything about Exim's UX, because reading the code (something I did a decent bit of back in the day) convinced me never to use it.
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).
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).
Sure. But if the "second-generation MTA" is next to impossible to learn how to configure, it doesn't really matter how good it is technically - it's unuseable unless configuring mail servers is literally your job, or you're happy copy-pasting someone else's config. Perhaps, one day, the Postfix people will realise that, but they apparently don't now.
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 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.
Tom, what on earth is a nth generation MTA? SMTP has largely remained static as a standard (when did that EHLO thing arrive?) for decades. OK, there are a lot of add ons such as SPF, DKIM and DMARC.
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.
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.
Thomas. :)
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.
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.
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!
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!
Related:
The DJB legacy - https://news.ycombinator.com/item?id=12600792 - Sept 2016 (9 comments)
The DJB legacy - https://news.ycombinator.com/item?id=12600792 - Sept 2016 (9 comments)
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.
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#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."
[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."
> 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.
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.
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.
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.
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.
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
[1] https://cr.yp.to/tcpip/minimalt-20130522.pdf
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
Seems very much alive, despite the dated feel of the reference => https://en.m.wikipedia.org/wiki/Daniel_J._Bernstein
Solid algorithmist.
Good grief the amount of pessimistic ignorance in this thread about someone who is quite literally devoting his life to our safe future.
He’s only 50. Is it a little early to talk about his legacy? Meaning, have we reached the end of his contributions?
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.
He was also still presenting before covid.
A legacy can be a work in progress.
rabite(1)
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.