Live data from Hacker News

Some thoughts on security after ten years of Qmail 1.0

blog.acolyer.org

81–90 of 123 posts

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

#81
post #39

Earlier quoted context omitted.

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…

> learning how to read and write dense code > and that's what I learned how to do This is good code? for(i=b=0;i t){r0(a);poop(f);R 0;}writer(f,kC(a),a->n);r0(a);if(!w)close(f);}if(b==r)R 1;q=0;o=0;a=ktn(11,0),v=ktn(0,0);}else{if((c-m)==10&& !strncasecmp(p+m,"connection",c-m))cf=p[s];js(&a,sn(p+m,c-m));jk(&v,kpn(p+s,e-s));}w=e=g=s=c=0;m=i+1;break; case' ':case'\t':case'\r':if(w&&!g)g=i;if(s==(e=i))++s;break; case':':…

It could be shorter if I spent some more time on it.

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

#82
post #62

Earlier quoted context omitted.

Yeah, I've completely stopped buying this idea that software engineers just need to do what all the other engineers do to improve. Let me know when someone engineers an n-dimensional bridge. For that matter, let me know when your engineers have built something as complex as the AWS infrastructure, by which I mean, every single service they offer, by information content (something like Kolmogorov complexity). There ar…

I think I agree that software engineering is more complex than building bridges if you take two comparable project. But I don't agree that software engineering is more complex than building rockets which requires - besides a lot physics know how - also deep understanding of electronics and hardware systems. And if we look at the Ariane 5, the software engineers failed.

An even more demonstrative example, the STS might (still?) be the most complex physical system ever.

The orbiter software group managed to not kill anybody with their software although there were some 17 bugs flown. The same cannot be said of the mechanical and human management systems, which killed one crew and possibly two.

Real software projects often fails for similar reasons, when somebody says "we know it's not designed for that condition, fly it anyway".

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

#83
post #74
post #63

Earlier quoted context omitted.

'When designing a building, one considers many "attacks" it can be subject to' Your use of scare quotes is appropriate, because there is a qualitative difference between intelligently-driven and unintelligent attacks. Not to mention the intelligently-driven attacks when the attackers are manifestly more intelligent and skilled than the defenders! If computer security experts didn't have to worry about intelligent att…

I'm no security expert, but this article, and the FastCo article about NASA programmers suggest, at least to me, that computer security is a problem that emerges from incompetence in using tools and designing programs. We're yet to make the differentiation between hacking away amateurishly and building a software solution that will be commercially offered. A showerthough I just though is that only companies registere…

"I'm no security expert, but this article, and the FastCo article about NASA programmers suggest, at least to me, that computer security is a problem that emerges from incompetence in using tools and designing programs."

While true that accounts for a large amount of the problem, probably the clear majority, computer security would remain a problem even if developers were uniformly highly competent. Competent use of existing crypto systems, which are broken three or four years later, would still be a problem. Meltdown and spectre would still be a problem. Building a safe execution sandbox is legitimately difficult.

But it would be a qualitatively different world than the one we live in.

Certification solutions to the software problem generally face the problem that it is very difficult to imagine any scenario other than one in which people grotesquely incompetent to write the certification rules are the ones writing them. We do not, for instance, want our certification authority to sit there and mandate waterfall design processes, which I would consider at least a 25%-probable outcome, and that's awfully large for something as catastrophic as that would be.

"WRT the house analogy, it's easy to extend that to "intelligent" attackers: intruders of any kind, e.g. robbers, animals, etc."

No, houses are never under such intelligent attack. Even when attacked by humans, they are not attacked by ninja stealth thieves who go in, photocopy your SS card, and get out again without leaving a trace or something that sounds absurd to even use as an example. There's no physical equivalent to breaking into millions of houses at a time and making off with such data. They're attacked by people who smash through the physical security. Anybody can do it. "Anybody" is who does it... above-average IQ people are not generally breaking into houses. (Above-average IQ criminals find much more lucrative and safe criminal hobbies.) Not just anybody can put a tap on a fiber optic line, feed it to a high speed data center, and process it in real time to extract out terrorism threat info, or even just exploit an XSS vulnerability on a website.

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

#84

Earlier quoted context omitted.

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/S…

The Tacoma Narrows bridge collapse happened 80 years ago, the Hyatt Regency was nearly 40. When did you last read about a software bug?

Professional engineering has plenty of recent disasters to point to, whether failures in design, construction, operation, or security:

The Waco fertilizer plant explosion (2013), cause determined to be arson (2016)

San Francisco Bay Bridge seismic bolt failures (2013), caused during construction: https://www.nace.org/CORROSION-FAILURES-San-Francisco-Bay-Br...

The Fukushima Daiichi nuclear disaster (2011), design/regulatory failure

And so forth: https://en.wikipedia.org/wiki/Category:Industrial_disasters_...

And so on: https://en.wikipedia.org/wiki/Category:Engineering_failures

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

#85
post #70

Earlier quoted context omitted.

Which also makes it a really silly choice for actual construction. Brick and concrete make a lot more sense.

Expanding and contracting is good. Steel also expands and contracts. Bricks and un-reinforced concrete crack and crumble.

Odd how this 1930s brick building I'm in right now hasn't crumbled apart, or even cracked from settling to any noticeable degree.

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

#86
post #47
post #24

Something to keep in mind with regards to qmail is that it's extremely feature-poor and it never got features beyond its initial design goal. This makes it much easier to keep the bugs out, to the point that making software under such constraints is much more similar to traditional construction projects. I mean: Nobody ever tells you after you have built a bridge that they are now going to upgrade gravity to gravity…

And you need these patches to fix what is IMO qmail's worst problem: backscatter. As far as I remember, when receiving an email with a forged return address to a non-existent mailbox, qmail first accepts the email, then sends a bounce message to the forged return address. Other MTAs (and patched qmail) reject the email directly in the SMTP session, preventing this issue. I personally consider this backscatter issue a…

That was definitely true, and it was the reason that I personally stopped using qmail in a previous (very long time ago now) job.

There were patches to fix the problem, along with offering useful features, but for whatever reason we went with exim (exim 3.x from Debian).

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

#87

Earlier quoted context omitted.

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.

I’ve never found a perfect 90 degree angle in any house, and I’ve built portions of quite a few. Wood expands and contracts with the seasons.

That's why they make protractors for measuring and cutting external baseboard trim. I've seen a few 90 degree corners, but not many.

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

#88
post #47
post #24

Something to keep in mind with regards to qmail is that it's extremely feature-poor and it never got features beyond its initial design goal. This makes it much easier to keep the bugs out, to the point that making software under such constraints is much more similar to traditional construction projects. I mean: Nobody ever tells you after you have built a bridge that they are now going to upgrade gravity to gravity…

And you need these patches to fix what is IMO qmail's worst problem: backscatter. As far as I remember, when receiving an email with a forged return address to a non-existent mailbox, qmail first accepts the email, then sends a bounce message to the forged return address. Other MTAs (and patched qmail) reject the email directly in the SMTP session, preventing this issue. I personally consider this backscatter issue a…

I worked at a web hosting company 1999-2005 that used qmail, and while there were many things wrong with qmail, due to it not being designed for the realities of email circa 2001, backscatter was by far the worst. We were processing significantly more backscatter than valid email, and to the best of my knowledge, the patches to address it didn't yet exist.

We certainly should have switched mail servers, but qmail was deeply ingrained in our home-grown hosting automation system, and it would have been a big deal to change.

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

#89
post #70

Earlier quoted context omitted.

Expanding and contracting is good. Steel also expands and contracts. Bricks and un-reinforced concrete crack and crumble.

Odd how this 1930s brick building I'm in right now hasn't crumbled apart, or even cracked from settling to any noticeable degree.

I'm guessing you've not been alive long enough to see the required maintenance that has been preformed on said building. People tend to miss and ignore things that aren't part of their profession

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

#90
post #61

Earlier quoted context omitted.

> 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 natura…

> You don't normally design with someone actively trying to destroy your building in mind. You do, actually. When designing a building, one considers many "attacks" it can be subject to, depending on the geography and demography of the site: what are the precipitation patterns like, what is the situation WRT sysmical activity, how is the soil, what is beneath, what is the crime rate in the area, what kind of animals…

I specifically said that physical security is an exception and "You design for some parameters (known wind speeds or local natural hazards)." These are all initial assumptions and known ahead of time.
Post reply on HN