Slashdot Mirror
A Developers Security Bugs Primer
CowboyRobot writes "ACM Queue's current issue on Open Source Security includes a short article by Eric Allman of Sendmail on how to handle security bugs in your code.
"Patch with full disclosure. Particularly popular in the open source world (where releasing a patch is tantamount to full disclosure anyway), this involves opening the kimono and exposing everything, including a detailed description of the problem and how the exploit works... Generally speaking, it is easier to find bugs in open source code, and hence the pressure to release quickly may be higher.""
Yes, such as "primer". "A (Developers' (Security Bugs) Primer)" is a valid way of describing a primer for developers regarding security bugs.
...which I don't really think now occur in sendmail at a higher rate than some other infrastructure bloatware. People are sometimes very slow to upgrade from very old versions, when problems were more common. For whatever reason (I lean toward complexity of administration), I see this a lot more often with mail systems than other infrastructure plumbing.
But here's a bit of irony: the ACMQueue article would seem to indicate that Allman believes in transparency. OK, the sendmail security page lives at:
http://www.sendmail.com/security/
But you have to know that, find it via Google, or just guess. When the page loads, you'll find a pagetop navigation bug at the Resources secion. But pull open the Resources section, and you find no link to it. Nor will you see it from the site map.
My overall take is that if you already know the ins and outs of sendmail admin (and other bits that it may be talking to, such as LDAP) you're running software which carries no greater than mainstream risk.
That said--this is complex software, and complexity is the enemy of security. If you're planning a new installation (particularly a small installation), and don't need all of sendmail's features, you should consider possible alternatives offerred by your Unix/Linux vendor.
What you do with a computer does not constitute the whole of computing.