You are right of course, the incentive-structure is completely messed up. For example, if Microsoft had to pay for all the losses their crappy products causes, OS/2 would never had had the marketing issues that killed it. Or if the ones using FOSS but contributing nothing would have to insure themselves against losses due to errors in FOSS from a certain level of usage intensity onwards.

The problem is that short-term-cheap is not anything that can ever work for things that need to be secure or reliable. And that the people making the decisions for what to buy are idiots or egoists (often both) and do not have to shoulder any of the effects of their bad decisions. Power without responsibility. That can never work. Most people will always optimize their short-term gains, because they do not understand or do not care about the long-term implications.

Indeed. Devs in large organizations cannot even talk to system administrators anymore these days (or rather they are forbidden to do so). And Sysadmins cannot talk to networking, and networking cannot talk to firewalls, and so on.

I have just recently had a project, where the application ops team was only allowed to talk to the network people directly in case of a dire incident. Yes, they knew who they where, had their phone numbers and had a working relationship. But the contracts enforced all communications to go through 1st level support and these people reject all things that are not immediate problems. Whoever thought that set-up would be a good idea should be fired on the spot. Instead, that idiot probably got a huge bonus for messing this up completely. One of the results is that when there are smaller network troubles, or when planning is to be done, things are delayed until there is a serious incident, because only then people that need to talk to each other are allowed to do so.

I disagree. Full control is the only way to enforce KISS. KISS is the only way to write secure software. Sure, a Garbage Collector, for example, sounds nice in theory, but in practice it is merely a tool that allows people that are too incompetent to do memory management to still use dynamic allocation. For example, with a GC you can never be sure freed memory is wiped before being re-used and that can change from one release to the next. Fully checked containers sound nice, but often it turns out they are not that fully checked, or have other limitations and bugs and quite often are not even fully documented. Talk about accidents waiting to happen. Only if you do them yourself can you be sure they indeed do what you think. And so on. I used to be a proponent of high-level languages for everything myself. Bit from what I have seen, they just make the problem worse when security is important.

Sure, if you do complex software, all these features help. But if you do complex software, it will be insecure. One thing that a language like C makes a lot easier is KISS, because as soon as you find you have to jump though hoops, you notice that you may be doing it wrong and too complex. Of course, if there were an alternative to C in low-level programming, that one would be just as viable. Since C is unique (unless you want to program assembler, that is), it has a special place. This may look like a "be-all hammer", but it is not and that is not the point.

Of course you should always strive to encapsulate the security-critical functionality and make it as small as possible (by KISS). Writing the rest in some modern language is perfectly fine and I am not arguing against that.

But the bottom line is that if the coder is not able to use full control competently, the coder is not qualified to write security-critical software. Mos coders are not qualified to write security-critical software, as we are seeing daily, no argument there.

As languages and tools are fundamentally incapable of "fixing" limitations of the people using them, I guess you are on the left-side of the Dunning-Kruger graphs as well. There is no replacement for a person that knows what he/she is doing. None at all. There never will be. Making this a language issue just serves to get more people into positions they are filling incompetently. They will then have negative performance, because they cause more problems than they solve. Building software with people that do not have what it takes is not economically viable, unless you are immoral scum that first establishes a monopoly and then puts all the cost of the broken software on the customers. Like Microsoft is doing for example. That is one reason why monopolies are incompatible with capitalism.

It is truly amazing how broken the US patent system is...

You obviously have never reviewed security critical "closed" code. I have. It is routinely a lot worse than the open code, exactly because almost nobody looks at it.

Yes, but for them _anything_ is unsafe.

Most programmers these days are "small skill". I blame IDEs and languages that coddle them and let "small skill" people produce something resembling code without understanding what they are doing. http://blog.codinghorror.com/t... is an eye-opener.

That idea does not work: In practice most programmers always create the most complex code they can. Hence code comprehension complexity is solely dependent on programmer skill. The other thing why this idea is flawed is that a good coder encapsulates complexity so that you do not have to "track more objects" in some languages.

A problem I have run consistently around is that developers rarely understand system administration, and operations in general. It makes their software suck a lot more. This is even more true with the Java-crowd, many of which cannot even use a commandline. The more this gets fragmented, the more people get specialized, the more problems arise in architecture, design and implementation, up to and including software that cannot even be deployed because of misconceptions on the developer's side.

The security level of a piece of code with good security is 95% coder competence and 5% language, i.e. language is irrelevant. One thing though is that language can add to the security problems if it has insecure tun-rime implementation errors.

One reason most security-critical software is written in C is that there, the coder gets full control. A good coder with skills in secure coding will do fine with C. A coder that does not understand software security will to badly in any language, but in C he/she might not even produce anything that works, which will be an advantage. Also in C, it will be far more obvious if somebody is clueless, which makes review easier.

But "language is important for code security" is even more wrong than "language is important for code reliability". Language is important for code performance though, but only in the sense that it can kill it. Good language choice can also make a good coder more productive (a bad coder has negative productivity, so it hardly matters...). This nonsense about the language being capable of fixing problems with the people using is comes from "management" types that are unable to handle people that are individuals. These utterly incompetent "managers" can be found in many large companies and they believe that in IT, individuals do not matter. Typically these "managers" are not engineers and have no clue what a good engineer can do but a bad one cannot. They also believe that engineering productivity can be measured in hours spent or that all coders are equal and just implement specifications, so outsourcing is a good idea.

Indeed. Most coders just add more code when they run into an issue. That is a problem for normal code, but it is death for anything security-critical.

You do know that the difference is that if this was closed source, we would just have heard about it a lot later, right?

Only for those of small skill. Those people should stay away from any security-critical code anyways.

That is complete BS. code is insecure because the coders suck. Language makes no difference. In a "safe" language, the bigs are just harder to find.