Schneier on Security

Clive Robinson • August 17, 2022 12:15 PM

@ Lucy B., Q, ALL,

Re : Correctly written software

“However, that’s predicated on the inability of programmers to write software correctly; if we could do that, auto-updates wouldn’t be needed. But we apparently can’t… “

But,

1, We have.
2, We Can.
3, We Do.

Write good software. I’ve written a lot of software that has no reported functional or security defects upto the time the software was EOL’d.

Some software I’m still supporting after four decades now… It was written for an Apple ][ in Pascal (UCSD) and has been ported a number of times, and has had updates as hardware became obsolete.

There was nothing magical or even exceptional about the way it was written, and we can still do the same if we wish to.

Bwck in the 1980’s people were still doing what had been the norm in the 1970’s and before which, was paying for bespoke development. It was howrver seen in the US as,

1, Expensive.
2, Slow.
4, Needlessly involved.

Because the first of the commercial / consumer applications were written using the same methodology they tended not to have issues.

However people wanted to “crank the money machine” and thus things had to be done faster, steps that money orientated investors saw as needless got pulled, the result was quality started to drop. Worse “kitchen sink marketing” came along and wanted a huge slice of the pie for basically makeing “dumbass promises to customers” just to make a sale.

The result was Micro$haft behaviour. But that is still not close to what we see today…

To crank the handle even faster we got the “code reuse” mantra. The problem was you had to write notvhalf a page to a page of code, but five to ten pages of “all things to all men” code, that unsuprisengly was not at all good.

One thing that happened was all sorts of input validation got removed.

Another was all exception handling got turned into “Blue Screen of death code”.

And the list goes on and on, every money man looking to,

1, Cut costs
2, Use less developer resources.
3, Cut proper design methods.
4, Outsource to the cheapest labour.
5, Preasure developers with too short time scales.
6, Add features that won’t be used but put vulnetable code in the tree.

And so on… And people wonder why their apps lock up, have security vulnerabilities and Crash out…

Annoying on a PC or Smart pad etc. But what about when “Things get physical?”

Those 737’s that dropped out of the sky was we know but people won’t officially admit was down to,

1, American Airlines being tight fisted.
2, Boeing marketing pandering to the AA executives black mail.
3, The money men pushing the aviation authorities to ease up on what the money men saw as needless.

I could go on but as any halfway comoetent engineer will tell you quality is a process that starts before a project and stays inplace for the whole project. As such it has rules that if you break them you will not get Quality, not even the illussion of quality, and yes when energy and matter are involved lack of quality kills, plain and simple.

Oh what sort of software methodology do you think Google and others are using for their self driving cars/trucks and unmaned aerial vehicles… I guess you probably do not want to know if you are ever going to get in one or alow one to come in range of you…