Slashdot Mirror


Software Code Quality Of Apache Analyzed

fruey writes "Following Reasoning's February analysis of the Linux TCP/IP stack (putting it ahead of many commercial implementations for it's low error density), they recently pitted Apache 2.1 source code against commercial web server offerings, although they don't say which. Apparently, Apache is close, but no cigar..."

16 of 442 comments (clear)

  1. apache 2.1? by fishynet · · Score: 5, Interesting

    2.1 is'nt even out yet! the latest is 2.0.46!

    --

    Cats: All your base are belong to us.
    Captain: Take off every sig !!
  2. Defect? by Jason_says · · Score: 5, Interesting

    Reasoning found 31 software defects in 58,944 lines of source code of the Apache http server V2.1 code.

    so what are the calling a defect?

  3. How do they get to look at closed source? by 3.5+stripes · · Score: 3, Interesting

    And don't most NDAs for when they do let you look forbid any competetive analysis?

    Or am I just too far out of that line of work to know how these things work?

    --


    He tried to kill me with a forklift!
  4. Interesting, with or without modules? by hughk · · Score: 3, Interesting
    If anyone has an Apache 2.1 dist around, they say they checked 58,000 lines - does this seem reasonable? Is this with any of the modules such as PHP or Perl or is this raw????

    I know that Apache has vulnerabilities but it should come better than IIS. You can't realisticly give a verdict on IIS without looking at the libraries called.

    As for the rest, I can imagine some commercial products coming in better, but not many.

    --
    See my journal, I write things there
  5. Does it matter? by pubjames · · Score: 5, Interesting


    So?

    There are errors and there are errors. There are error that don't matter a jot, and there are errors that are show-stoppers.

    I've worked on banking software containing code that was written in assembly for PD11s and developed over decades. The most horrible spaggetti code you could ever imagine. Why did the banks keep using it? Because for any particular input it always gave the correct output.

    Years of bug fixing had made the code horrible and probably full of errors if you were looking at it from a purely theoretical/software engineering viewpoint. But from an input/output point of view, it was faultless.

  6. That's so weird ... by SuperDuG · · Score: 3, Interesting
    I found just the opposite.

    Important Tech City, CA, July 7th 2003
    For Immediate Release
    Sbj: Apache beats other webservers

    Recently we had our staff (some guys kid) look over the source code of 3 major webserver packages available, in that code nearly 8 million lines of error were found, but surprisingly the damned things still worked?!

    We placed a performance test (click a link and see if porn comes faster) with apached and 3 other commercial offerings. Apache seemed to knock them all of the water, boy will those other three companies be mad now.

    While we cannot tell you what the other three offerings were (that might make this whole thing more believeable) we can tell you that we think they're popular.

    Here's the results

    Apache ------------------- 104
    Com 1 --------32
    Com 2 -----------45
    Com 3 ---------------53

    As you can see by the clear test results, apache wins in all tests.

    Since when are unfounded results from a company that doesn't explain what the "32 defects" were, newsworthy. Don't act like these guys are worth my time, this is bullshit.

    --
    Ignore the "p2p is theft" trolls, they're just uninformed
  7. to be expected from Open Source by Illserve · · Score: 3, Interesting

    By its very nature, Open source will tend to fix important bugs and leave unimportant ones unfixed, while standard QA processes associated with commercial software will tend to fix little UI issues during the release schedule before dealing with vulnerabilities.

    So seems pretty clear to me that in Open source, the ratio of showstopper bugs to miscolored widget bugs will be much lower than for commercial software.

  8. Re:So if they found them... by tomstdenis · · Score: 5, Interesting

    Agreed. Things like splint often report "warnings" on code that shouldn't be. For instance

    int some_func(char *somebuf)
    {
    if (somebuf == NULL) return ERROR;
    somebuf[0] = 'a';
    return OK;
    }

    Will generate a warning with splint saying "pointer may be null" despite the fact it cannot be.

    Those tools are generally too sensitive and give too many false positives to be useful in the long run.

    Tom

    --
    Someday, I'll have a real sig.
  9. Useless information presented confusingly by albin · · Score: 4, Interesting

    Slashdot's summary of this article is way off base, and the article itself couldn't be less useful. Counting the number of "errors" in lines of code... and the ratio is supposed to mean something to us? As compared to unnamed other software? C'mon, I have better things to do with my time.

    *plonk*

    --
    A hen is only an egg's way of making another egg. -- Samuel Butler
  10. Re:Code defects appear to be a small part of the e by bwt · · Score: 3, Interesting


    One of the best ways to get to know a large code base like Apache or something else is to find a repeatable bug and track it down. To fix a bug you do not need to understand the whole program, just the relevent parts. I've submitted bug fixes to several projects, so I must strenuously disagree, especially because, ahem, I have never submitted a bug fix to a proprietary project because its impossible.

  11. Apache 1.3? by Spazmania · · Score: 4, Interesting

    First, as many posters have noted, Reasoning DID NOT TEST APACHE 2.1. They tested Apache 2.1-dev. That's dev, as in development branch. As in: I have new untested code, so don't use me on a production server until I'm released in the STABLE series.

    For a valid comparison versus commercial software, the testers should have used Apache 2.0.46, the most current STABLE series release.

    Second, I'd be interested to see a comparison of 2.0.46 versus 1.3.27. I have a pet theory that multithreaded C code has more bugs than single-threaded C code, and I'd like to see whether there is evidence to support it.

    --
    Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
  12. Re:Code defects appear to be a small part of the e by jdh-22 · · Score: 3, Interesting

    You have the wrong idea here. There is a point in which you must realize what information you can release without comprimising the security of your system. While I can give you the plans to my vault, I will not give you the combination, nor the first or second numbers in it.

    For the star wars geeks out there, if you were a Jedi, you don't go around telling everyone you're a Jedi, nor do you flash your light saber in public places. They do realize when to show their light saber, and when they can tell people they are a Jedi. Nor do they not tell anyone who they are, or never show their lightsaber.

    You might want to check out Secrets and Lies which will give you a better understanding of security philosphy.

    --
    Every Super Villan uses Linux.
  13. Re:Defect is too strong a word... by DrInequality · · Score: 3, Interesting
    Defect is way too strong. Take Defect 1. Can only possibly derefence a NULL pointer if a number of preconditions are true. The last one is (!conf->providers)[the pointer in question] must be false.

    !!conf->providers => conf->providers => conf->providers != NULL

    Their program has detected "defects" where there are none. Perhaps the greater coding style variation on open source projects exposes more defects in their automated program!

  14. Re:Code defects appear to be a small part of the e by aziraphale · · Score: 5, Interesting

    One word: architecture.

    And not just the architecture of the web server, but the architecture of the entire platform. But specifically looking at the architecture of Apache versus the architecture of IIS, you'll immediately see that the goals of the two pieces of software are not the same. Look at things like IIS's metabase - the structural details of the server's configuration are kept in an in-memory data structure, which is easily modified while the server is running. Apache, in contrast, reads its configuration at startup, and uses it to determine which modules of code are loaded, and how they are used to process requests - fixing the behavior of the web server at startup.

    IIS follows typical MS enterprise software design - it has to interface with COM, and the NT security model, and active directory, and the registry, and a million other systems, all in the name of integration, and enterprise management. Apache doesn't have PHBs telling it that it needs another way for the metabase to be edited, or a new instrumentation API, or whatever else a particular large customer asked for - and can get on with just providing its facilities cleanly.

    That's why IIS has so many more security holes, even if it does (as may or may not be the case) have the same raw coding error rate as Apache.

  15. Worst kind of science by AYEq · · Score: 4, Interesting

    Reasoning's code inspection service is based on a combination of proprietary technology and repeatable process.

    Am I the only one who looks at reasoning's results with suspicion (even when I agree with them). Any analysis using methods that are not open and repeatable is not science. This just feels like marketing to me. (it is sad because the study of code quality is such a worthwhile pursuit)

  16. prove it. by Mark19960 · · Score: 4, Interesting

    they dont say what they used for a comparison.
    when they tell us what they used, then I will believe it.
    this smells microsoft.

    bring it on! we want to know what it was compared against, sure as hell was NOT IIS...