4 ms·

How to Write Software with Zero bugs – 25 years after qmail 1.0 – D. Bernstein [pdf]

34 points by bykhun 3y ago

daneel_w 3y ago
Does anyone know how qmail has fared since this PDF was written in 2007? Did it make it to 2023 without any bugs surfacing?
- commandersaki 3y ago
  https://lwn.net/Articles/820969/ https://lwn.net/Articles/820969/
  - emailsysadmin 3y ago
    no one in their right mind keeps qmail-verify active for many reasons.
- troutwine 3y ago
  It didn't make the transition to 64 bits worth of memory with the record intact. https://lwn.net/Articles/820969/ https://lwn.net/Articles/820969/ Although the CVE _is_ from 2005 so perhaps it doesn't count.
  - literalAardvark 3y ago
    I mean... I'd say expecting a program written for a 32 bit OS to just work on 64 is excessive. And the fix is just to add mildly sane memory limits to the processes, which is an OS level task, thus, not necessarily a bug. Not that the whole thing was very well handled.
    - troutwine 3y ago
      I would argue that the fix is for the software to refuse to function if it can detect that it's in an environment where it won't function safely, to fail-closed rather than fail-open.
      - literalAardvark 3y ago
        Fair enough, that's a good idea.
hdmoore 3y ago
Erm, qmail had lots of bugs[1], when compiled for 64-bit processors (lots of integer overflows), but djb pushed back and said 64-bit wasn't supported. If anything, qmail is known as the most annoying MTA to package, since no modifications to the source are permitted, and the application has to be built using a massive patch tree instead. The quirky management daemons required to run qmail were also obnoxious and at odds with everything else on the system. Salient quote below: >In May 2005, Georgi Guninski published "64 bit qmail fun", three vulnerabilities in qmail (CVE-2005-1513, CVE-2005-1514, CVE-2005-1515): [snip] >Surprisingly, we re-discovered these vulnerabilities during a recent qmail audit; they have never been fixed because, as stated by qmail's author Daniel J. Bernstein (in https://cr.yp.to/qmail/guarantee.html https://cr.yp.to/qmail/guarantee.html): >>"This claim is denied. Nobody gives gigabytes of memory to each qmail-smtpd process, so there is no problem with qmail's assumption that allocated array lengths fit comfortably into 32 bits." 1. https://www.qualys.com/2020/05/19/cve-2005-1513/remote-code-execution-qmail.txt https://www.qualys.com/2020/05/19/cve-2005-1513/remote-code-... edit: added quote from referenced url
- jiggawatts 3y ago
  Reminds me of the era when dual-core processors started becoming generally available. Suddenly the bugs in multi-threaded software were much more apparent. Vendors replied to complaints with: “We don’t support those processors”. No buddy, you don’t support stable software. It’s buggy even on a single core, it’s just less obvious.
  - stefan_ 3y ago
    It's a very interesting phenomenon. There are lots of claims along the lines of "a single CPU is so fast it will exercise all kinds of multi-threading patterns very quickly" but in my experience it indeed takes multiple processors to reliably show up various races and faulty implicit orderings.
    - jiggawatts 3y ago
      Single processors interleave threads using very coarse "quantums" of execution, where each thread runs for many milliseconds at a time. Dual processors will run the instruction streams truly in parallel. From a correctness perspective, they're "identical", because even on a single core a context switch can occur anywhere. In theory, even one core can interleave individual instructions, it's just not done for performance reasons. So if multiple cores causes a crash, then that crash bug was always there, and could have occurred even on a single core. It's just much less likely to be triggered. Thankfully now every mainstream computer and practically all phones are multi-core, so software has to be written properly. The early 2000s were a mess though, with a lot of heisenbugs that were maddening to track down.
latenightcoding 3y ago
Classic paper but what the hell is this title .
kens 3y ago
The title of the actual paper is "Some thoughts on security after ten years of qmail 1.0". The post currently has the made-up title "How to Write Software with Zero bugs – 25 years after qmail 1.0 – D. Bernstein [pdf]".
- bykhun 3y ago
  Sorry, that's actually how I jokingly refer to that paper whenever I quote it, I didn't know the title should match the link title exactly. Now I see why it's flagged
- SushiHippie 3y ago
  Also the publication year of the pdf is 2007, which is also missing
- jrpelkonen 3y ago
  It is also somewhat ironic that the editorialized title has an off-by-one bug in it: It has been 26 years since 1997.
technick 3y ago
I have PTSD from listening to my friends complain about qmail back in the early 2000's.
gerdesj 3y ago
I ran several Qmail systems. Daemontools worked rather well. They had a habit of delivering email reliably. "Life with Qmail" was a very decent primer. I also ran several other mail systems at the same time (and still do). Exchange's smtpd is still a bit of a pain and I never put it on the internet directly. Nowadays (last 15 years) I use Exim for a MTA/proxy - at home and at work.
- GauntletWizard 3y ago
  I feel like Pottering owes a lot to daemontools; A lot of the good ideas of Systemd come from there, as does the sense of smug superiority.
  - actionfromafar 3y ago
    Daemontools is smug, Systemd declares itself triumphantly the Emperor and Lord Protector of our light cone!
  - Karrot_Kream 3y ago
    > as does the sense of smug superiority. Ouch I never made this connection but now that you bring it up, I can't unsee it.
- Karrot_Kream 3y ago
  Any reason you prefer Exim? I've enjoyed running Postfix forever and though the config is a bit baroque, have had no issues with running it in my somewhat weird setup.
  - gerdesj 3y ago
    Exim has a rather mad ACL etc system which is what I need. Postfix is absolutely ideal for receive mail, pass to AV/spam checker, pass it on (or not). Exim is hugely configurable. If you use it on Debian/Ubuntu and you have somewhat complex needs then ditch the split config thingie and simply create your own /etc/exim4/exim4.conf from scratch. You can test a config with "exim -bhc <ip.add.re.ss>" to simulate a SMTP session from <ip.add.re.ss>, before you restart Exim to make the config active. So: helo me mail from: name@example.co.uk rcpt to: name@another.example.co.uk data etc etc At each stage you get a debug output of what would happen. You have to be a bit careful with this because a new Exim daemon will use the new config. For small changes do it "inline", for major changes, copy the conf to a new name and specify it with -C and test until it works. There are a lot of options. Documentation is complete for Exim. If you find a flaw then Jeremy and co will fix it - the Exim devs are very, very driven, for want of a better word. You will get short shrift on the mailing lists if you obviously haven't tried to do any research but you will soon get some extremely knowledgable help if you show willing. No Disqus etc - just old school mailing lists and that is the way it should be. The big boys are destroying SMTP gradually but it can and does still work, if you are careful. EDIT: <formatting>
jongjong 3y ago
I agree with the argument about reducing lines of code. Whenever I write code, I spend quite a bit of time thinking about different ways of implementing it before I start coding and the most important characteristic I look for in a solution is succinctness. Correct code is easy to read because it's close to its theoretical minimum size. It reminds me of the quote "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."
deleted 3y ago
[deleted]
lockhouse 3y ago
Why is this flagged? This is one of the few posts that are actually on topic for HN.
johnea 3y ago
Good to see the DJBway here. So much could be learned in modern *nix distributions from this philosophy...

34 points by bykhun 3y ago

Does anyone know how qmail has fared since this PDF was written in 2007? Did it make it to 2023 without any bugs surfacing?

commandersaki 3y ago
https://lwn.net/Articles/820969/ https://lwn.net/Articles/820969/
- emailsysadmin 3y ago
  no one in their right mind keeps qmail-verify active for many reasons.
troutwine 3y ago
It didn't make the transition to 64 bits worth of memory with the record intact. https://lwn.net/Articles/820969/ https://lwn.net/Articles/820969/ Although the CVE _is_ from 2005 so perhaps it doesn't count.
- literalAardvark 3y ago
  I mean... I'd say expecting a program written for a 32 bit OS to just work on 64 is excessive. And the fix is just to add mildly sane memory limits to the processes, which is an OS level task, thus, not necessarily a bug. Not that the whole thing was very well handled.
  - troutwine 3y ago
    I would argue that the fix is for the software to refuse to function if it can detect that it's in an environment where it won't function safely, to fail-closed rather than fail-open.
    - literalAardvark 3y ago
      Fair enough, that's a good idea.

hdmoore 3y ago

Erm, qmail had lots of bugs[1], when compiled for 64-bit processors (lots of integer overflows), but djb pushed back and said 64-bit wasn't supported. If anything, qmail is known as the most annoying MTA to package, since no modifications to the source are permitted, and the application has to be built using a massive patch tree instead. The quirky management daemons required to run qmail were also obnoxious and at odds with everything else on the system. Salient quote below: >In May 2005, Georgi Guninski published "64 bit qmail fun", three vulnerabilities in qmail (CVE-2005-1513, CVE-2005-1514, CVE-2005-1515): [snip] >Surprisingly, we re-discovered these vulnerabilities during a recent qmail audit; they have never been fixed because, as stated by qmail's author Daniel J. Bernstein (in https://cr.yp.to/qmail/guarantee.html https://cr.yp.to/qmail/guarantee.html): >>"This claim is denied. Nobody gives gigabytes of memory to each qmail-smtpd process, so there is no problem with qmail's assumption that allocated array lengths fit comfortably into 32 bits." 1. https://www.qualys.com/2020/05/19/cve-2005-1513/remote-code-execution-qmail.txt https://www.qualys.com/2020/05/19/cve-2005-1513/remote-code-... edit: added quote from referenced url

jiggawatts 3y ago
Reminds me of the era when dual-core processors started becoming generally available. Suddenly the bugs in multi-threaded software were much more apparent. Vendors replied to complaints with: “We don’t support those processors”. No buddy, you don’t support stable software. It’s buggy even on a single core, it’s just less obvious.
- stefan_ 3y ago
  It's a very interesting phenomenon. There are lots of claims along the lines of "a single CPU is so fast it will exercise all kinds of multi-threading patterns very quickly" but in my experience it indeed takes multiple processors to reliably show up various races and faulty implicit orderings.
  - jiggawatts 3y ago
    Single processors interleave threads using very coarse "quantums" of execution, where each thread runs for many milliseconds at a time. Dual processors will run the instruction streams truly in parallel. From a correctness perspective, they're "identical", because even on a single core a context switch can occur anywhere. In theory, even one core can interleave individual instructions, it's just not done for performance reasons. So if multiple cores causes a crash, then that crash bug was always there, and could have occurred even on a single core. It's just much less likely to be triggered. Thankfully now every mainstream computer and practically all phones are multi-core, so software has to be written properly. The early 2000s were a mess though, with a lot of heisenbugs that were maddening to track down.

latenightcoding 3y ago

Classic paper but what the hell is this title .

kens 3y ago

The title of the actual paper is "Some thoughts on security after ten years of qmail 1.0". The post currently has the made-up title "How to Write Software with Zero bugs – 25 years after qmail 1.0 – D. Bernstein [pdf]".

bykhun 3y ago
Sorry, that's actually how I jokingly refer to that paper whenever I quote it, I didn't know the title should match the link title exactly. Now I see why it's flagged
SushiHippie 3y ago
Also the publication year of the pdf is 2007, which is also missing
jrpelkonen 3y ago
It is also somewhat ironic that the editorialized title has an off-by-one bug in it: It has been 26 years since 1997.

technick 3y ago

I have PTSD from listening to my friends complain about qmail back in the early 2000's.

gerdesj 3y ago

I ran several Qmail systems. Daemontools worked rather well. They had a habit of delivering email reliably. "Life with Qmail" was a very decent primer. I also ran several other mail systems at the same time (and still do). Exchange's smtpd is still a bit of a pain and I never put it on the internet directly. Nowadays (last 15 years) I use Exim for a MTA/proxy - at home and at work.

GauntletWizard 3y ago
I feel like Pottering owes a lot to daemontools; A lot of the good ideas of Systemd come from there, as does the sense of smug superiority.
- actionfromafar 3y ago
  Daemontools is smug, Systemd declares itself triumphantly the Emperor and Lord Protector of our light cone!
- Karrot_Kream 3y ago
  > as does the sense of smug superiority. Ouch I never made this connection but now that you bring it up, I can't unsee it.
Karrot_Kream 3y ago
Any reason you prefer Exim? I've enjoyed running Postfix forever and though the config is a bit baroque, have had no issues with running it in my somewhat weird setup.
- gerdesj 3y ago
  Exim has a rather mad ACL etc system which is what I need. Postfix is absolutely ideal for receive mail, pass to AV/spam checker, pass it on (or not). Exim is hugely configurable. If you use it on Debian/Ubuntu and you have somewhat complex needs then ditch the split config thingie and simply create your own /etc/exim4/exim4.conf from scratch. You can test a config with "exim -bhc <ip.add.re.ss>" to simulate a SMTP session from <ip.add.re.ss>, before you restart Exim to make the config active. So: helo me mail from: name@example.co.uk rcpt to: name@another.example.co.uk data etc etc At each stage you get a debug output of what would happen. You have to be a bit careful with this because a new Exim daemon will use the new config. For small changes do it "inline", for major changes, copy the conf to a new name and specify it with -C and test until it works. There are a lot of options. Documentation is complete for Exim. If you find a flaw then Jeremy and co will fix it - the Exim devs are very, very driven, for want of a better word. You will get short shrift on the mailing lists if you obviously haven't tried to do any research but you will soon get some extremely knowledgable help if you show willing. No Disqus etc - just old school mailing lists and that is the way it should be. The big boys are destroying SMTP gradually but it can and does still work, if you are careful. EDIT: <formatting>

jongjong 3y ago

I agree with the argument about reducing lines of code. Whenever I write code, I spend quite a bit of time thinking about different ways of implementing it before I start coding and the most important characteristic I look for in a solution is succinctness. Correct code is easy to read because it's close to its theoretical minimum size. It reminds me of the quote "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."

deleted 3y ago

[deleted]

lockhouse 3y ago

Why is this flagged? This is one of the few posts that are actually on topic for HN.

johnea 3y ago

Good to see the DJBway here. So much could be learned in modern *nix distributions from this philosophy...