| > We would get rid of some issues if we used a safer language, but the real issue is that we don't find the issues, the attacker does instead. So people are finding the issues, but why are not the people writing the software finding them? Attackers aren't finding all the issues. They are finding issues in the small subset of software they actually bother to examine. That programmers aren't finding the issues I think illustrates both the effort it takes to always be correct as well as the different skills that are leveraged differently. It doesn't take a good C systems or application programmer to find a lot of the common C unsafety errors in question. It takes someone that knows the C memory model and has the knowledge of how to leverage that commonly. In some cases it takes someone applying new fuzzing techniques to expose certain edge cases more consistently that prior fuzzers did. > That means you run the same tests, no matter the language, so in the end it doesn't matter what language you write it in. The important point you are assuming is that the language (or current implementation of it) won't change out from under you in a way that makes that assumption invalid. See my other comment in this discussion regarding DJB, and the HN comment I link to for a good discussion about why that's so. > And you chose a language that fits the problem, you don't make the language fit the problem. In what case when you have two languages roughly similar in capability but one allows errors the other doesn't is the one that allows the errors the better fit? > So I think your analogy of an airbag is wrong in some sense. The issue isn't weather we have an airbag or not, the issue is that we don't test if we have an airbag and then go "Whoops, the airbag didn't deploy in the crash and somebody died". Then you're misunderstanding my analogy. The car isn't the program written, the car is the compiler. The route driven is the program. You may make an error on the drive, but let's let the car save us in those cases where it's obvious it can and should. Sure, making sure your coworkers check you've secured the pillows to the steering wheel before every trip works, but it should be obvious why that's sub-optimal in multiple dimensions. > I work at a place where we have written code for 15 years, not only C code, or more without any remote exploitable holes. I congratulate you on your diligence (sincerely, it is an accomplishment to get to the level where you feel you can say this), but that's a strong assertion in at least one possible interpretation. Perhaps you meant no remotely exploitable holes found? The interesting question that immediately arises from that clarification is whether anyone has seriously looked? Companies that care about this hire pen testers. I hope yours does as well. |