Live data from Hacker News

Some thoughts on security after ten years of Qmail 1.0

blog.acolyer.org

31–40 of 123 posts

Re: Some thoughts on security after ten years of Qmail 1.0

#31
post #23
post #19

Earlier quoted context omitted.

In the UK, you can build a bridge without certification as long as you have someone certified review the plans and the implementation before anyone else drives on it. I suspect this is similar for most civilised countries. A (perhaps short-term) idea would be to make software vendors liable, and do not permit them to sign away that liability.

I completely agree. But the vendor situation looks very different for software. Imagine being the sole person responsible for migrating Linux from ip/nftables to ebtables. You don't know how your stuff will be used downstream. So you license it with text in all caps reminding people that your software is provided WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PU…

Those people who build oil pipelines should be able to sue whoever sold them the Linux distribution (probably Red Hat or IBM) which was vulnerable to that weird keepalive message.

In that case, a judge (and perhaps a jury) could hear how Red Hat did everything they possibly could to protect from the vulnerability as evidenced by their ISO QA processes and the fact that everyone else was vulnerable to the same "bug" … or from the other side how Microsoft and Apple weren't at-risk, so Red Hat should've caught it.

C[I]SOs would want to be patched, because ISO recommends they would be patched.

> You can't really fault the people responsible when many companies simply require good damage control over actual security in order to be successful.

Which is why I propose legislation, so "good damage control" wouldn't be enough.

You better believe that oil company would want some evidence of testing and proper specifications, and to have them reviewed by a couple independent parties if the government could take them for a percent of gross revenue for the security vulnerabilities alone.

Re: Some thoughts on security after ten years of Qmail 1.0

#32
post #26

My biggest takeaway from qmail has nothing to do with security, but rather that excessively restrictive licensing, highly opinionanted/unusual setup, and unwillingness to collaborate on its development squandered its potential. If it wasn't for all that, we might well all be using qmail-based mail servers today, as qmail was really ahead of its time in so many ways. It was kind of like the Amiga of mail servers, back…

> …highly opinionanted/unusual setup… That setup contributed to security. It also made qmail very easy to extend: I operated a medium-sized mail service a while ago and qmail's pluggability meant I could add features that didn't exist in other mail servers (like postfix or exim) without forking the entire project. * I had SMTP AUTH when the only other mail server to support it was Netscape; before RFC2554 was written…

> I wish the model had caught on, because it's a superior way to develop software. I didn't understand why though until fifteen years later...

Can you elaborate?

Re: Some thoughts on security after ten years of Qmail 1.0

#33
post #28
post #4

As we cast about trying to figure out ways to make software more secure or reliable, please remember that in other engineering fields (civil, chemical, mechanical, etc.) prioritizing safety and reliability is a _solved problem_. (1996) https://www.fastcompany.com/28121/they-write-right-stuff > It is perfect, as perfect as human beings have achieved. Consider these stats: the last three versions of the program — each…

I read an article many many years ago explaining why software engineering can't be compared to mechanical engineering. I can't find it now, but one of its points of comparison was: if a nut isn't tightened enough on a bridge, you can tighten it a bit more -- turn the nut 3 or maybe 6 millimeters more. In software engineering, if you tighten the nut only 3 millimeters instead of 6, one of the bridge's endpoints now en…

If you're building houses, and your walls are a "few centimeters" off from straight, you'll get a real asswhoopin'.

Especially if you're building something with more than one story, and you expect people to actually pay for it.

Re: Some thoughts on security after ten years of Qmail 1.0

#34
post #20

Earlier quoted context omitted.

This is a fine sentiment, but it's hardly a bright-line rule. We don't criticize Twitter's handling of abuse or fascists because they promised us a platform free of abusive fascists; Twitter didn't promise us shit except 140 character messages. All the problems were emergent. So many of the great (financial) success stories of our sector are about startups stumbling into an untapped demand, and then running with it f…

Bullshit. Justify the recent Hawaii emergency notification in the context of an airliner. You can't because we would never tolerate that kind of unreliability in our transportation infrastructure. Twitter does what it says on the tin. That doesn't mean software engineering is a mature discipline.

In a sense, software engineering is quite mature. It's probably matured a lot faster than most other engineering branches.

We know about static analysis, fuzzing, unit testing, integration testing, functional testing, Continuous Integration/Deployment/Delivery, etc., etc.

It's just that maturity costs a lot of money. 95% of the software produced just doesn't need that and the client can't even afford it.

Re: Some thoughts on security after ten years of Qmail 1.0

#35
post #4

As we cast about trying to figure out ways to make software more secure or reliable, please remember that in other engineering fields (civil, chemical, mechanical, etc.) prioritizing safety and reliability is a _solved problem_. (1996) https://www.fastcompany.com/28121/they-write-right-stuff > It is perfect, as perfect as human beings have achieved. Consider these stats: the last three versions of the program — each…

You over-estimate the degree to which the other engineering fields you mentioned have solved safety and reliability. Just to name a few:

- Tacoma Narrows bridge: https://en.wikipedia.org/wiki/Tacoma_Narrows_Bridge

- Thalidomide: https://en.wikipedia.org/wiki/Thalidomide

- Hyatt Regency walkway collapse: https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse

- Challenger disaster: https://en.wikipedia.org/wiki/Space_Shuttle_Columbia_disaste...

- Columbia disaster: https://en.wikipedia.org/wiki/Space_Shuttle_Columbia_disaste...

- Vioxx: https://en.wikipedia.org/wiki/Rofecoxib

...and plenty more. The only thing that separates software engineering with the other engineering disciplines is that there is a structure (usually in the form of code/spec enforcement) for internalizing and learning from disasters when they happen.

Re: Some thoughts on security after ten years of Qmail 1.0

#36
post #26

My biggest takeaway from qmail has nothing to do with security, but rather that excessively restrictive licensing, highly opinionanted/unusual setup, and unwillingness to collaborate on its development squandered its potential. If it wasn't for all that, we might well all be using qmail-based mail servers today, as qmail was really ahead of its time in so many ways. It was kind of like the Amiga of mail servers, back…

> …highly opinionanted/unusual setup… That setup contributed to security. It also made qmail very easy to extend: I operated a medium-sized mail service a while ago and qmail's pluggability meant I could add features that didn't exist in other mail servers (like postfix or exim) without forking the entire project. * I had SMTP AUTH when the only other mail server to support it was Netscape; before RFC2554 was written…

Having strong personal convictions about security and architecture was one of the primary reasons that tinydns and qmail were the staples that they were.

Yes, they have been feature locked for a long time. But let's not pretend that collaboration in 1996 was anything like it is today. And let's not pretend that there haven't been a plethora of security issues in all kinds of software that simply haven't befallen Bernsteins' software as a direct result of how he managed the projects.

I had the distinct impression that "dominating the market" was never a thought in his mind. He wrote the software he wanted to write and shared it. It was good software. It's still being used by many people.

The man isn't infallable. He isn't always right. But whenever I paid attention to him, he was right a lot more frequently than he was wrong.

The fact that he wasn't driven by dollars or market dominance was a good thing.

I, for one, admire the man and his software.

Re: Some thoughts on security after ten years of Qmail 1.0

#37
post #4

As we cast about trying to figure out ways to make software more secure or reliable, please remember that in other engineering fields (civil, chemical, mechanical, etc.) prioritizing safety and reliability is a _solved problem_. (1996) https://www.fastcompany.com/28121/they-write-right-stuff > It is perfect, as perfect as human beings have achieved. Consider these stats: the last three versions of the program — each…

> in other engineering fields (civil, chemical, mechanical, etc.) prioritizing safety and reliability is a _solved problem_.

One big difference between those and programming is that there (outside of military, physical security, and few other exceptions) there are no active adversaries for your project. You design a X that will serve a defined purpose. You design for some parameters (known wind speeds or local natural hazards).

You don't normally design with someone actively trying to destroy your building in mind. You don't design thinking how to avoid the current issues and to isolate the impact of potential future attackers. Your product doesn't have a "well funded attackers will spend undefined amount of time trying to make your project fail" requirement.

Re: Some thoughts on security after ten years of Qmail 1.0

#38

Earlier quoted context omitted.

Well, Maildir was invented by djb ;-)

DJB is probably one of my favorite people in the tech world. Ever since I read about the court case he won against the US government while representing himself , he's been a sort of hero of mine.

That's quite impressive, but Wikipedia says that case was dismissed: https://en.wikipedia.org/wiki/Bernstein_v._United_States

Re: Some thoughts on security after ten years of Qmail 1.0

#39
post #32
post #26

Earlier quoted context omitted.

> …highly opinionanted/unusual setup… That setup contributed to security. It also made qmail very easy to extend: I operated a medium-sized mail service a while ago and qmail's pluggability meant I could add features that didn't exist in other mail servers (like postfix or exim) without forking the entire project. * I had SMTP AUTH when the only other mail server to support it was Netscape; before RFC2554 was written…

> I wish the model had caught on, because it's a superior way to develop software. I didn't understand why though until fifteen years later... Can you elaborate?

Which part. The model? The article explained it well enough. I think of it as two main parts: (1) make fewer bugs, and (2) show your users the correct way to do things (which is the inverse of getting the correct requirements).

Or are you asking what took me fifteen years to understand?

Dan basically planned the whole thing. When the whole thing was too big, he would break off a piece that wasn't and develop it as a wholly separate thing.

I understood this strategy worked, but I didn't fully understand why this strategy was successful until I realised source code matters more than I thought[1]: If your program is short enough, there won't be any bugs in it. This is why learning how to read and write dense code[2] can make your programs better -- and that's what I learned how to do[3].

[1]: http://www.jsoftware.com/papers/tot.htm

[2]: http://www.nsl.com/papers/origins.htm

[3]: https://github.com/geocar/dash/blob/master/d.c#L62

Re: Some thoughts on security after ten years of Qmail 1.0

#40
post #4

As we cast about trying to figure out ways to make software more secure or reliable, please remember that in other engineering fields (civil, chemical, mechanical, etc.) prioritizing safety and reliability is a _solved problem_. (1996) https://www.fastcompany.com/28121/they-write-right-stuff > It is perfect, as perfect as human beings have achieved. Consider these stats: the last three versions of the program — each…

From the article (1996): And it’s the dominant image of the software development world: Gen-Xers sporting T-shirts and distracted looks, squeezing too much heroic code writing into too little time; rollerblades and mountain bikes tucked in corners; pizza boxes and Starbucks cups discarded in conference rooms; dueling tunes from Smashing Pumpkins, Alanis Morrisette and the Fugees. Its the world made famous, romantic,…

I can't tell if you're being sarcastic or not in your second paragraph. :-)
Post reply on HN