71–80 of 164 posts
Earlier quoted context omitted.
If he takes that stance than it will cast doubt on everything else he has done. If there is a footgun on the wall, by the end it must go off, and chaining "non-exploitable" bugs together is routine stuff for hackers.
It's been 20 years; I don't think he's concerned.
Does anybody still use qmail in Production. I see on DJB's website that it is used in 700K sites but I doubt that assumption. Also the code has not been updated in almost a decade. How or why do sysadmins decide to go with qmail in 2020
"Finally, we also discovered two minor vulnerabilities in qmail-verify (a third-party qmail patch that is included in, for example, Debian's qmail package): CVE-2020-3811 (a mail-address verification bypass), and CVE-2020-3812 (a local information disclosure)." The vulnerabilities were introduced in a third party patch, not source code that was authored or advocated by djb. "As recommended by Daniel J. Bernstein, qma…
""https://cr.yp.to/qmail/guarantee.html has for many years mentioned qmail's assumption that allocated array lengths fit comfortably into 32 bits. I run each qmail service under softlimit -m12345678, and I recommend the same for other installations.""
Earlier quoted context omitted.
It's not "they", it's Daniel J. Bernstein. That's the reason :) (If you don't know: he is a top cryptographer that can amazingly correct code. However, he also has a very big ego...)
I don't understand. Most people with a big ego would not want a critical vulnerability associated with them. Can you elaborate?
Do we know if they have applied for the $500 bug bounty from DJB?
Yeah, it was denied. About our new discovery, Daniel J. Bernstein issues the following statement: "https://cr.yp.to/qmail/guarantee.html has for many years mentioned qmail's assumption that allocated array lengths fit comfortably into 32 bits. I run each qmail service under softlimit -m12345678, and I recommend the same for other installations." And from his "guarantee" In May 2005, Georgi Guninski claimed that some…
-m12345678
"Finally, we also discovered two minor vulnerabilities in qmail-verify (a third-party qmail patch that is included in, for example, Debian's qmail package): CVE-2020-3811 (a mail-address verification bypass), and CVE-2020-3812 (a local information disclosure)." The vulnerabilities were introduced in a third party patch, not source code that was authored or advocated by djb. "As recommended by Daniel J. Bernstein, qma…
Which patch are you talking about? I don't see anything about a patch in the CVE.
> Seems much simpler than patching, let alone trusting someone else's patches.
We can patch the issue for good (and with a simple patch, apparently), or we can rely on users not to mess with seemingly unrelated init scripts. Do you trust third party users more than a (likely heavily scrutinised) small third party patch?
Does anybody still use qmail in Production. I see on DJB's website that it is used in 700K sites but I doubt that assumption. Also the code has not been updated in almost a decade. How or why do sysadmins decide to go with qmail in 2020
I was using Courier MTA for a while for self-hosting email.
I may do so again, and will likely use mailcow or mail in a box. Neither are based on qmail.
Oh, dear. Another "will never happen" issue which, after not so long (in the history of mankind) takes place. And this one would not have been so complicated to fix (just enforce a limit as the author suggests). /* this line is unreachable */ printf("You have reached unreachable code\n"); 10 years later, it gets printed...
(paraphrased from a friend's answering-machine message)
Oh, dear. Another "will never happen" issue which, after not so long (in the history of mankind) takes place. And this one would not have been so complicated to fix (just enforce a limit as the author suggests). /* this line is unreachable */ printf("You have reached unreachable code\n"); 10 years later, it gets printed...