Ok, I just read this ZDNet post (via LinuxToday) and I have to say something about it.
As you probably can see from the rest of this blog, I’m a linux user. But I’m also an IT consultant (I know, I know…but it’s better than working for a company, at least for somebody with the weird sleeping habits I have :) who mostly specializes in network security…and I absolutely disagree with Dana Blankenhorn in this.
First of all, Coverity and their project. This is a company, that together with Stanford University, has decided to do an audit of “over 30 of the most critical and widely used open source projects in the world” and they’ve done this by applying “the latest innovation in automated defect detection to uncover some of the most critical types of bugs found in software”.
So…for starters…which company out there is doing something like this with Windows? or OSX? or any other proprietary Operative System? Right, none. Nobody can do something like this with a proprietary OS because…nobody has access to the source of those, unlike it happens in the FLOSS universe.
Second, the number of fixes…they’ve fixed 3198 bugs since the project started in march of this year…and I applaud them for it. I don’t know how critical these bugs have been, but it doesn’t really matter…they’ve caught over 3,000 bugs and squished them. How many bugs have been fixed in Windows in the last 3 months? In OSX? Heaven knows…but the real problem is…nobody has a clue about how many bugs *exist* in either of those OSes, because nobody *can* do an audit of them like the one Coverity is doing on linux.
The quote about it taking a year to secure open source…come on! First of all, saying that something is 100% secure is bullshit. Nothing is 100% secure in any aspect of human life and environment. There’s people that die while taking a shower, there’s people that die while eating, there’s people that die while sleeping…nothing in life is secure, you just have more or less secure than something else. So…the title of the article is 100% bullshit.
But even if we take the title of the article to say “in a year open source will be more secure than today”, we have to look at how things work in the software world, FLOSS or proprietary.
When code gets added to a program, any program, bugs get introduced. They can be big mistakes (somebody forgot to parse the result of a database query and got a buffer overrun which allows code excecution by a user) that result in security breach or they can be small mistakes (the program’s output is spitting numbers with two decimals but due to the nature of the data, you’ll never see anything but the first decimal used) that have no real consecuences. The cause of these mistakes can be almost anything, from a typo (instead of a closing parethesis you stick in a closing square bracket in a function) to a thinko/brain fart (you skipped a line in the function you are copying from your test program to your production program) or it can be a matter of lack of sleep/rest (programmers in crunch time tend to rest very very little, cfr this article from 1995) or working with a cold or just lack of knowledge or experience.
Some of these bugs get discovered when you try to complie the program the first time and your compiler spits at you; other times, they get discovered when you run the program the first time; and yet some other times, it’s not until a user does something you’ve never thought of doing (a friend of mine used to like to hunt bugs for some projects…some of the bugs he found needed 10 steps or more in a certain order to be triggered); and some bugs only get found if you do what Coverity is doing, a code audit.
The real problem with all of these, is that none of the programs that they are auditing is a program that is no longer being developed. Looking at the list of projecs they have on their main page, you can see stuff like the linux kernel, KDE, Gnome, gcc, OpenOffice.org…it’s a huge list! And all of those projects work in internet time, doing releases as fast as they can. So…the target that Coverity is auditing changes daily, which means they have to take one of two approaches:
a) Stop at a version and audit that fully. This is more or less what Debian does with their stable distribution. They stop updating to the latest and greatest and just do stabilization work on it until they deem it fit for the “debian stable” lable. The problem with this is that by the time the audit is done, the programs being audited have been left behind by the project, and stuff that they’ve found may be in code that has already changed or that has been dumped to the side. And the users are probably using the latest release from the project and won’t get to use the improved old release that you are auditing.
b) Follow the latest version. The problem with this is that you have a *lot* of code to audit every single day. The kernel changes every day in the unstable side, KDE and gnome do too. Hell, Enlightenment, which is a window manager that is not as big a project as KDE or gnome, gets 20 or 30 cvs submits every single day (I’ve seen days of over 100 submits). Keeping up with as many projects as they follow must be a daunting thing.
The way they are doing it is by using automated systems to do the auditing. That is, it’s not people looking at code and trying things, it’s programs checking programs, which tends to make things go a lot faster than doing it by hand, but it also has its problems. There are bugs that can’t be detected by reading the code, which means that an automated system looking through code will not catch them.
On the other hand, automated systems for code auditing are expensive as all hell, so having somebody saving programers’ time by running their code through these programs is a good thing, and helps a lot. Automated code auditing isn’t going to catch every bug, but it’ll catch a whole lot of bugs that may escape from a human audit, just because the auditing program “knows” all the rules for the language and the human may forget or get mixed up in some aspects of it and not realize that what he just read was actually wrong.
So…in a year a whole lot of the bugs that exist today in the software they are auditing will be gone, and most probably the programs they are auditing *will* be more secure than they are today…but there will be new bugs that aren’t there today.
So…no matter how you look at it, the title of the post is bullshit.
On the other hand, the Coverity project *is* a very good thing for linux and FLOSS. The more people and companies we have hunting for bugs in the programs we use, the less bugs us, the users, will have to deal with, and that is always A Good Thing. We, the FLOSS community, are thankful for all the work that Coverity and Stanford U have saved our programers and users :)
After reading all of this stuff, you are probably asking yourself…ok, and the objective of all of this is…what? And I’ll answer it in a few words:
Stuff like the Coverity project is imposible to do with proprietary software because only the company that owns the software can look at the code, so…what would you rather use, software that can be audited by people who know how or software that *nobody* can audit?
I know what my answer to that is.
Technorati Tags: open source, coverity, software security, linux, open source
Tags: Thoughts
If you enjoyed this post, make sure you subscribe to my RSS feed!!
