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.
The majority of their revenue is from the US military. That has a certain type of impact.
I hope there will be a backlash and some Linux distros will remember that reliability was one of the Linux promises. Currently it does not look good, with Gentoo the only somewhat major distro that has not decided to join the clusterfuck. (Slackware is another.) On the other hand, current Debian stable does not have it either, and that will be around for a few years, so if people wise up to how stupid and non-UNIX systemd is soon enough, they _could_ go back. I may also be dreaming here, but my impression is that the negative voices with regard to systemd are increasing. Basically everybody with a clue that takes one look at this monster immediately does not like it.
There are people not on SysV init? That shows even it is already more complicated than needed. Excellent!
I am not sure it is a bigger issue, since many of these sites will not be publicly reachable. But it definitely is an issue foe example for large corporations that use SSL in their Intranet with self-signed certificates. They now have to wonder whether some of their staff has attacked their servers this way.