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
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
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).
Security Web Tools", Gary Bahadur talks about a few freeware Linux tools
that can be used to perform footprint and vulnerability analysis,
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?
Paradigm: Shift Happens
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.
Quick or Good?
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
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?