Slashdot Mirror

← Back to Stories (view on slashdot.org)

Apache 2.0.40 Released

Posted by michael on from the apt-get dept.

cliffwoolley writes "On August 7, the Apache Software Foundation was notified of a significant vulnerability that affects the Win32, OS/2, and Netware ports of Apache 2.0. It has the potential to allow an attacker to inflict serious damage to a server and/or reveal sensitive data on those platforms. To fix this vulnerability in addition to a number of cross-platform issues (a pair of path exposures and a number of bugs), Apache 2.0.40 has been released. It is considered the best currently available version of Apache, and all users are urged to upgrade."

3 of 35 comments (clear)

  1. Re:PHP? by cos(0) · · Score: 4, Interesting

    PHP 4.3.0 which is still in CVS has full (not experimental) support for Apache 2 and has had it for months now.

  2. Re:Apache and security by Electrum · · Score: 3, Interesting

    OK, I'm not a Linux man: but I didn't think Linux actually supported proper asynchronous I/O. And the acryonym, for better or for worse, is still LAMP and not FAMP or SAMP (or even SAOP). (WISA, anyone? :-) ) Sure, you can pass a shed-load of sockets into a select() call but I can't see select()'s efficiency being even close to linear in set size.

    Linux does not support the POSIX AIO interface with a standard kernel (SGI has an implementation available). The supported Linux method is realtime signals. While there is probably a good reason that they chose this non standard, Linux specific method (besides the "because we can"), I haven't seen anything documenting the reasoning.

    Another method, /dev/epoll, is somewhat similar to Solaris' /dev/poll. It is more efficient and has (IMHO) a cleaner interface than the realtime signals. Hopefully this patch will make it into the mainstream kernel.

    The following page is an excellent reference on I/O models: http://www.kegel.com/c10k.html

    And, yes, both select() and poll() both have scalability limits somewhere after a few thousand descriptors. However, a non blocking server using these will still be much more scalable than a multiprocess blocking server such as Apache. The overhead of that many processes will kill you.
  3. Re:Apache and security by mckayc · · Score: 1, Interesting

    So then start your own webserver project if you seem to know what all the problems are with Apache. I would be interested to see the outcome and if it's all you say it would be, I would probably even use it.