Jack Wallen is at it again, trying to talk about what he doesn’t know. For some reason, in trumpeting his support for open source software, he like to act like he knows how software is written and released. And in his latest article regarding the recently-publicized GHOST vulnerability, he oversteps the boundaries of his knowledge by a large margin and makes a lot of statements that show clearly he has no idea how software is written and released (yet TechRepublic for some reason allows him to publish his tripe), he also has a major bias against “proprietary software”.
Within moments of the flaws discovery, it was revealed which versions were safe, and patches were on the way.
Moments? You and I have a different idea of what “moments” means.
The vulnerability in question is identified as CVE-2015-0235. How quickly did Qualys discover the flaw, and then discover in which version the vulnerability no longer existed? Given the extent of the research published in their own bulletin on the vulnerability, it certainly wasn’t “moments”. That took *a lot* of effort, and it was only at the end of it they made word of the vulnerability public. The entry for the vulnerability report was created in mid-November, meaning the security flaw was first identified around that time.
The second the patches are rolled into libc6, they’ll be released without hesitation, and systems will once again be safe.
Released without hesitation? You need to look at the release history for glibc6. They go *months* between releases. They just happened to get lucky in that this flaw was already patched unwittingly by another developer, likely while going after something else.
There’s very little bureaucracy in the way of releasing major bug fixes — it just happens and happens with an efficiency no proprietary software can match.
No proprietary software can match it? Here’s a suggestion, Jack: when thinking of “proprietary software”, stop thinking of only companies like Microsoft.
“Proprietary software” is written by large and small companies alike. In my previous job, there were times we went from phone call to released patch within hours — and that’s with a closed-source, proprietary project. I write closed source software in my spare time, and there’ve been several times I’ve released a patch to a bug the same day it’s been reported, sometimes also within hours.
Open source is no different in how bugs and security holes are found and patched than closed source applications. Even the release process really isn’t much different. Unfortunately in some industries, the release process is hampered by laws and regulations, and if an open source application is targeted toward those particular industries, they must also comply with those regulations.
Here’s how it actually works.
Once a bug is reported, it needs to be investigated to be confirmed to exist — given the extent of Qualys’s report on the issue, they were extensive in their investigation. Once confirmed, code is patched, but it’s not necessarily as quick a process as you imply. A candidate fix for the bug needs to be thoroughly tested to ensure it will (hopefully) not introduce new issues — this is going to be especially true in libraries with a lot of consumers, such as glibc. Unit testing can help in this instance, but it’s not perfect.
And bugs and security flaws vary on how easily they can be patched. Larger code bases are likely going to be more difficult to patch, depending on the flaw, where it exists within the code base, and the consumers of that code. What on the surface might seem like a simple fix may require some re-engineering to completely resolve, something I’ve had to do a few times.
Again closed source vendors can also have patches out just as fast and how fast a patch is rolled out has nothing to do with whether it is open or closed source.
And with larger projects, it often makes more sense for periodic service releases than it is to constantly release incremental versions with small changes. Again, looking at the release dates for glibc, they go *months* between releases. The tags in their Git repository also reflect going months between releases. My employer, to contrast, rolls out service releases every month on a set schedule.
