In this issue

Those waiting since April for a new 2.0 beta will have to keep on waiting after another release candidate, 2.0.27, was abandoned this week when a bug was discovered while running the code on the live apache.org server. Some httpd processes were found to be stuck in infinite loops while reading POST requests; the bug was traced to the code handling request bodies. After fixes for this bug and a build problem on BSD/OS were checked in, the tree was tagged ready for a 2.0.28 release.

An unfortunate side effect of some recent optimisation work in 2.0 was an increase in the number of "lstat" system calls made during request processing. It was discovered during benchmarking this week that this had in fact adversely affected performance: with one report of a 20% drop in the "requests per second" count.

In this section we highlight some of the articles on the web that are of interest to Apache users. This week we focus on security.

The administrator at cgisecurity.com looks at some common fingerprints used in port 80 exploits with a few examples on how each attack signature may be implemented. It covers common malicious requests, commands which may be executed by worms, files which may be requested by attackers, buffer overflows, and hex encoding. Although it is not meant to be an exhaustive list, it is sufficient to help web server administrators identify attack patterns in their logs, and to add the appropriate rules to their Intrusion Detection Systems (IDS).

In "Freeware Security Web Tools", Gary Bahadur talks about a few freeware Linux tools that can be used to perform footprint and vulnerability analysis, the first two phases of a web server security assessment. Among the tools mentioned are Nmap, Netcat (nc), Whisker, Cgichk.pl (a Perl-based scanner), Malice (also a Perl-based scanner), and Md-webscan.

Linuxfocus.org brings us the second article in a series about using Lire to analyse the log files of many different services. It teaches us how to customise the generated reports by choosing which reports Lire should generate, and setting the various parameters for these reports.

PHP, a server-side HTML-embedded scripting language, offers web developers the convenience of generating dynamic page content, and supports a wide range of databases but PHP programs are vulnerable to security compromises if they are poorly written. "On the Security of PHP, Part 1" aims to minimise this risk by offering some guidelines on secure PHP programming practices. It begins with an overview of PHP, and then examines some of the most common security issues with PHP programs.

The Apache Web server has been around for several years now. ASF board member Ken Coar poses the question of whose purposes is its development serving now?

In the November 1997-January 1998 timeframe, two significant changes happened in the way development of the Apache Web server occurred. The first was the move from a 'review-then-commit' (RTC) model to a 'commit-then-review' (CTR) one; the second was to move the project status into the repository.

Prior to the change from RTC to CTR, any alteration to the source code needed to be proposed to the development mailing list, and garner at least three positive "looks good to me" votes from qualified developers, before it could be committed and made part of the server. The change to CTR meant that changes could be made by anyone with access, at any time. Big or controversial changes still needed to go through the review-first process, however.

This change allowed highly-motivated developers to operate in a sort of 'rapid prototype' mode, so changes that had been languishing for lack of sufficient interest were able to be committed and the coders could move on.

Of course, the downside was that changes got committed with less peer review, and might either be broken or have side-effects on other developers' work or other parts of the server.

As for the commitment of the project status record to the repository itself.. well, that too had advantages and disadvantages. Previously the status was maintained by a volunteer (usually Jim Jagielski), who collated the list of outstanding change proposals, who had voted for what, and open problems or issues, and mailed it to the list at semi-regular intervals. Once the file was in CVS, the mailing could be (and is) done automatically at regular intervals, and developers could express their opinions directly by recording their votes in the status file.

One of the downsides I personally perceived as a result of these changes was that the developers on the mailing list narrowed their focus. They could commit whatever they were working on, as long as no-one else objected retroactively, and so their work didn't get proposed or even make it into the status file -- it went straight into the code. In addition, with the freedom to update both the source and the status at will, changes proposed by newcomers sometimes didn't get recorded in the status file, and were occasionally ignored altogether, because the developers were paying more attention to scratching their own itches than to reviewing other people's work.

Fortunately, the situation didn't get as bad as it could have, and several of the developers now responsibly record and respond to proposals from people new to the mailing list.

A third facet of change that can be seen on the Apache jewel is the composition of the developer community. Over time, it seems to have shifted somewhat from exclusively hackers and bit-twiddlers who ran Web sites to people with formal software engineering background who are employed by companies that use or redistribute software based on the Apache package. One of the side-effects of this, I think, is an increased awareness of, and attention paid to, Apache's market share. It used to be cool, but now many people consider it important as well.

Does all this mean that the forces driving the development of the Apache Web server have changed over time? I think so. Are the directions in which development is now heading right for the software's users? What do you think?