LAMP Lights the OSS Security Way

Kevin Young wrote to mention a ZDNet article which goes into some detail on new results from a Department of Homeland security initiative. It's called the 'Open Source Hardening Project', and (funded to the tune of $1.24 Million) the goals of the initiative are to use a commercial tool for source code analysis to buck up the security base of many OSS projects. LAMP (the conglomeration of Linux, Apache, MySQL, and PHP/Perl/Python) was a 'winner' in the eyes of the project. From the article: "In the analysis, more than 17.5 million lines of code from 32 open-source projects were scanned. On average, 0.434 bugs per 1,000 lines of code were found, Coverity said. The LAMP stack, however, 'showed significantly better software quality," with an average of 0.29 defects per 1,000 lines of code, the technology company said.'"

Maybe I've been reading too much politics lately..

[Valdrax]

Maybe I've been reading too much politics news lately, but I'm just waiting for Microsoft to come out with a statement that people capable of evaluating Perl, PHP, and Python are biased in favor LAMP solutions.

I need to do something about my cynicism.

Counting Defects

[RasendeRutje]

How can one ever count the defects/bugs per line?
And why count them, and then not remove them?
And one huge defect is better than more than one small ones?
Sounds like a crappy research to me, time to RTFA.

http://scan.coverity.com/ - highest/lowest

[digitaldc]

As part of the government-funded effort, Stanford and Coverity have built a system that does daily scans of the code contributed to popular open-source projects. The resulting database of bugs is accessible to developers, allowing them to get the details they need to fix the flaws, Coverity said.

Just an FYI...AMANDA had the highest amount of bugs at 1.214 Defects / KLOC and OpenVPN the lowest at 0.100 Defects / KLOC.

Re:Fucking LAMP.

[Trevin]

I'd love it if database management systems were compatible enough to allow that. The trouble is, it seems only the most basic query syntax has been standardized. Several other aspects, such as table creation, column types, auto-increment variables, and stored procedures, have varying degrees of differences or support between the various databases such that in any sufficiently complex application you would need to write a separate copy of db interface code for every DBMS that you want to support.

LA - fine M - okay P - ah so many varieties!

[Dareth]

The LAMP stack when broken down consists of:
Linux & Apache - rock solid stable releases.
MySql - Okay, getting better with each release.

P - This is the kicker. Perl, Python, PHP, and more so lately even that R one Ruby & Rails.
We are living in interesting times when we have so much choice... much like the Chinese curse. I do not see as how you can evaluate all of these platforms together in a general fashion. Where is the skew or bias in this study?

Someone on IRC recently was critical of a small website I put together in 2000. It was written in plain html, using frames *gasp*. Many people today do not realize how far web development has come since then.

Re:Fucking LAMP.

[mrops]

Hey that why I say LAMP will never take the place of say Java/spring/hibernate/tomcat/jboss.

Re:don't waste that $$$!

[ChrisA90278]

Why not release the results of all the bugs? All those OSS projects will then have 0.00% bugs!

Many other studies and most programmers experiance shows that there is a high likelyhood of introducing a bug whenever you make a change to existing code, In fact on a per line of code written basis "fixes" are about the buggyist code you can write. So if you have .3 bugs per KSLOC (Kilo lines of code) in mature code like Apache orthe Linux kernal the new stuff that fixes a bug might have three times as many bugs per line. But the bug fix is typically small, many time just one to four lines so you do make projess. Over tiome the "defect rate" falls. Graphically it is a curve to reaches zero at infinity.

"Everyone" knows the above so after even a triveal fix you test the heck out of the system then put it though a long beta cycle. Well, at least the projects that have some kind of process in place do this. But note that all the "best" OSS systems sdo have a very strong and well ordered developent process. I'd say the low bug rate is due to the process. The best they can do is make incremental tweeks to the process and wait. At infinity the bug rate will in fact reach zero, or so says the theory.

Re:Counting Defects

[Pedro Sobota]

Very Bad, and I have seen a US Defense - contracted software company (they even do helicopter systems) on their website extensively touting their 'lower defects per line of code (DLC)' methodology. Marketing.

bug reports?

[Janek Kozicki]

17500000 lines of code, 0.434 bugs per 1000 lines, that makes 17500*0.434=7595 bugs, so where are the bugreports?

Re:Fucking LAMP.

[Malor]

SQLite doesn't seem to be very fast. I know the SlimDevices people are having some trouble with it. They write SlimServer, an open-source Perl server that indexes music and drives the company's (excellent) Squeezebox players.

The problem seems to happen when people have very large collections, greater than 10,000 tracks... updates become slow, and the whole system gets a little sluggish. Apparently, when using MySQL, the problem goes away completely... or at least until someone gets to 100k tracks or something. :)

Perhaps the Slim team is doing something wrong, but they're definitely seeing some performance issues with SQLite.

Re:Fucking LAMP.

[Decaff]

Several other aspects, such as table creation, column types, auto-increment variables, and stored procedures, have varying degrees of differences or support between the various databases such that in any sufficiently complex application you would need to write a separate copy of db interface code for every DBMS that you want to support.

There are open (and closed) source products that have dealt with these issues for years. Modern ORMs products handle all of these matters, and automatically provide translation between portable query languages (such as JDOQL) and high-performance vendor-specific SQL depending on the database you deploy on.

It is astonishing to see these matters still being discussed as if no solution exists!