Some thoughts on security after ten years of Qmail 1.0 • Hacker News Board

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

#11

Post by mulmen » Wed, Jan 17, 2018, 8:05 AM UTC

Joeri wrote: post #8

diafygi wrote: 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…

The difference is that while you can’t make a bridge in your bedroom you can make an app. Should we forbid people from writing code without the proper certification? Should we close down the open internet and replace it with a regulated zone where only compliant software can be run? I agree that we need a higher standard of engineering in software, but I’m not clear on how to achieve it without draconian measures.

I made a lot of bridges and cranes in my bedroom. They all failed spectacularly but GI Joe didn't seem to mind that the shear strength of a Lego pin was inadequate to support his tank.

The difference is that I don't then promise a municipality that I can build them a bridge that can take their citizens across a river, even in case of a 100 year event. Or an early warning system that can save their citizens from nuclear holocaust. This is the difference in maturity between software "engineering" and real engineering disciplines.

You're free to experiment with your own resources but as soon as you make a promise to the public or your customers you should be required to meet your promises in all circumstances.

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

#12

Post by arca_vorago » Wed, Jan 17, 2018, 8:08 AM UTC

zAy0LfpBZLC8mAC wrote: post #7

djsumdog wrote: post #5

Earlier quoted context omitted.

I remember qmail being the first MTA to really push Maildirs. I ran qmail personally back then on my Linux fom Scratch, but I also was a student lab admin and I think on our student e-mail server, we still ran sendmail at the time, on good old Redhat (back before it was split into RHEL and Fedora). Software like qmail and the dev file system at the time really rubbed a lot of people the wrong way because of the drast…

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.

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

#13

Post by pmoriarty » Wed, Jan 17, 2018, 8:08 AM UTC

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 in the day. It could have easily dominated the market, but it wound up a mere historical curiosity.

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

#14

Post by diafygi » Wed, Jan 17, 2018, 8:10 AM UTC

Joeri wrote: post #8

diafygi wrote: 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…

The difference is that while you can’t make a bridge in your bedroom you can make an app. Should we forbid people from writing code without the proper certification? Should we close down the open internet and replace it with a regulated zone where only compliant software can be run? I agree that we need a higher standard of engineering in software, but I’m not clear on how to achieve it without draconian measures.

Hmmm, I think it's too early to tell.

After all, we've witnessed move-fast-and-break-things social networks (Facebook, Twitter, Reddit) that had no desire to influence society in a big way get hijacked by state actors to achieve political goals.

We're also witnessing toasters having web servers pre-installed on them with no thought into what happens if the company that pushes patches (if they do at all) goes bankrupt, thus creating vast oceans of botnets that the rest of us now have to deal with.

Again, I think there's a long road ahead of hard lessons when we don't take our own power in software seriously.

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

#15

Post by fh973 » Wed, Jan 17, 2018, 8:23 AM UTC

diafygi wrote: 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 think the difference is that in engineering you are legally obliged to follow this process and in software you are not.

The leads to a race to the bottom for which both the software vendors and consumers are responsible. Everybody wants the latest stuff as soon as possible, and wants to play less. If you release software only when everything's "right", the market will have moved on.

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

#16

Post by BurritoAlPastor » Wed, Jan 17, 2018, 8:24 AM UTC

mulmen wrote: post #11

Joeri wrote: post #8

Earlier quoted context omitted.

The difference is that while you can’t make a bridge in your bedroom you can make an app. Should we forbid people from writing code without the proper certification? Should we close down the open internet and replace it with a regulated zone where only compliant software can be run? I agree that we need a higher standard of engineering in software, but I’m not clear on how to achieve it without draconian measures.

I made a lot of bridges and cranes in my bedroom. They all failed spectacularly but GI Joe didn't seem to mind that the shear strength of a Lego pin was inadequate to support his tank. The difference is that I don't then promise a municipality that I can build them a bridge that can take their citizens across a river, even in case of a 100 year event. Or an early warning system that can save their citizens from nucle…

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 for as long as the money lasts. Nobody sets out to build a bridge – they build a 2x4 plank, and then realize that rather a lot of people want to walk on it.

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

#17

Post by geocar » Wed, Jan 17, 2018, 8:31 AM UTC

fh973 wrote: post #15

diafygi wrote: 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 think the difference is that in engineering you are legally obliged to follow this process and in software you are not. The leads to a race to the bottom for which both the software vendors and consumers are responsible. Everybody wants the latest stuff as soon as possible, and wants to play less. If you release software only when everything's "right", the market will have moved on.

> If you release software only when everything's "right", the market will have moved on.

... unless we the people demand legislation that protects us from software "vendors" selling us their bugs.

I think it's interesting that people can see a car that doesn't work, and a house that's falling apart, but they can't really see software. Can you imagine someone saying "my house is leaking" and the landlord saying, with all seriousness: "Have you tried turning it off and on?"

Of course, we have legislature for those things, so why not software?

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

#18

Post by cageface » Wed, Jan 17, 2018, 8:33 AM UTC

diafygi wrote: 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…

Follow the money. If people were willing to commit to a specification with the same level of precision as a civil engineering blueprint and then stick to that specification then you’d see a dramatic uptick in software quality, along with a dramatic uptick in price and time to develop. But since hardly anybody wants to commit to that kind of precise design or pay the cost we get what we have today instead.

Come to SE Asia and I’ll show you plenty of civil engineering projects with similarly poor planning and execution.

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

#19

Post by geocar » Wed, Jan 17, 2018, 8:37 AM UTC

Joeri wrote: post #8

diafygi wrote: 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…

The difference is that while you can’t make a bridge in your bedroom you can make an app. Should we forbid people from writing code without the proper certification? Should we close down the open internet and replace it with a regulated zone where only compliant software can be run? I agree that we need a higher standard of engineering in software, but I’m not clear on how to achieve it without draconian measures.

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.

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

#20

Post by mulmen » Wed, Jan 17, 2018, 8:38 AM UTC

BurritoAlPastor wrote: post #16

mulmen wrote: post #11

Earlier quoted context omitted.

I made a lot of bridges and cranes in my bedroom. They all failed spectacularly but GI Joe didn't seem to mind that the shear strength of a Lego pin was inadequate to support his tank. The difference is that I don't then promise a municipality that I can build them a bridge that can take their citizens across a river, even in case of a 100 year event. Or an early warning system that can save their citizens from nucle…

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.