Hacker News new | past | comments | ask | show | jobs | submit login

> The vulnerabilities were introduced in a third party patch

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?




qmail-verify. It is an "update" of the third party "realrcptto" patch by another third party. It says "third party patch" right there in the sentence I quoted. There is no qmail-verify in original qmail.

As to the second question, I trust softlimit from daemontools and that is what I use. https://cr.yp.to/daemontools/softlimit.html

Not sure what "messing with seemingly unrelated init scripts" means. Can you be more specific?


I could trust softlimit all right, but my point was that I wouldn't trust users to wield it correctly.


softlimit is not difficult to use, certainly no more difficult than patch. programs like tinydns-conf for example autmatically generate a run script containing softlimit with a recommended -m setting. maybe qmail needs something similar.


I was talking about patching upstream, okay? It's not like the patch would have to be individually applied to each installation by its own admin. Patch upstream once, and poof, all users worldwide are safe as soon as they update.


Perhaps "Seems much simpler than patching" was an ambiguous statement. I was only referring to the perspective I take as an admin for one user: me. I already use softlimit on a daily basis so it is simpler for me than patching. To me, it seems like a cleaner solution. The two complete mitigations presented were a choice between (a) using softlimit and the -m setting used by qmail's author versus (b) applying a third party patch to fix problems caused by another third party patch (qmail-verify, which was an "upadte" of yet another third party patch) and third party configuration settings (Debian). I thought that was noteworthy.


Correction: With tinydns, it's a -d setting, not an -m setting




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: