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."

22 of 35 comments (clear)

  1. PHP? by buzzbomb · · Score: 5, Informative

    PHP support for Apache 2.0.x is still marked as expirimental. Until that's changed, I can't even think of upgrading.

    1. Re:PHP? by caferace · · Score: 1
      It is a drag. We'd like to use it as well, but it simply doesn't play well, especially with 4.2.1

      -jim (who found the cgi/cgid path exposure in 2.0.39)

    2. 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.

    3. Re:PHP? by Micah · · Score: 3, Insightful

      Isn't CVS almost by definition experimental? If it wasn't experimental it would be released as 4.3.0!

      And then there's mod_perl, which is also apparently in beta for Apache 2. I'd upgrade if I could reliably run Slashcode under that.

    4. Re:PHP? by Anonymous Coward · · Score: 2, Informative

      There's not a stamp of "stable" or "experimental". For me the performance of the CVS builds have been stable. I don't know what that's worth.

    5. Re:PHP? by MattRog · · Score: 1

      Problem is things like Zend Accelerator do not work with Apache 2 yet. :(

      As soon as PHP4 and Apache 2 play nicely (it wasn't setting cookies correctly on some browers for some reason??) and Zend (et al) solutions work on it we can't use it, although we are REALLY looking forward to it (the hybrid thread model is neat-oh).

      --

      Thanks,
      --
      Matt
    6. Re:PHP? by MORTAR_COMBAT! · · Score: 2

      all kinds of issues.

      PHP 4.3.0 is essential, because the new features of Zeus 2.0 (try/catch, etc, etc) I use heavily. However I have had all kinds of problems getting PHP to work with Apache2, since 2.0.29 seemingly broke PHP...

      --
      MORTAR COMBAT!
    7. Re:PHP? by Anonymous+Conrad · · Score: 1

      Congratulations on having production requirements. What the hell does that have to do with this article? I suppose he's saying, "Why bother releasing? It ain't all that great."

    8. Re:PHP? by Spaaaaaam · · Score: 1

      For me the performance of the CVS builds have been stable. I don't know what that's worth.

      Not much.

  2. Re:Apache and security by buzzbomb · · Score: 3, Insightful

    So the Apache group has once again proven that they can deliver both a slow and insecure web server. How many more security holes will Apache have before it is "secure"? And when will Apache deliver truly high performance by having a non blocking I/O model?

    When will you stop bitching and join the Apache devel team to help make it secure? When will you submit a non-blocking I/O patch to the Apache codebase?

    If you don't like the direction they are going, either don't use it or join the devel team. There's no need to bitch and moan about it like it intimately affects your life.

    Apache is NOT the fastest out there...but it is the most configurable (PHP, Perl, etc) and the best all-around webserver there is. Many of us think that the Apache team has done great work and we apprieciate every minute of it.

  3. Re:Apache and security by alan_d_post · · Score: 2, Troll

    Why isn't there a fast (non blocking) web server that supports fast dynamic content such as PHP, either built in (yuck) or through an API like FastCGI, available for UNIX platforms?

    Many programs have yet to be written. Perhaps this is one of them. Maybe you'd like to write it? I think you'll be much happier if you stop expecting people to do things for you.

  4. Re:Apache and security by swordfish666 · · Score: 1

    See what M$ has done. They have reduced people to thinkng that they (the people) cannot change things.
    Change. This is what OpenSource is all about.

    Granted the Apache group is large and the voice of one may not be immediately heard but it only takes the voice of one to start things moving.

    By not bitching and instead finding a way to change things is what makes us different from them.

    For them "There is no choice, there is only M$." (quote found on the web) but for us it is "Find a way or make one." (personal life philosophy)

    Cheers

    --
    I like-a do-the cha-cha.
  5. Re:Apache and security by Pathwalker · · Score: 4, Informative

    It sounds to me that either Roxen or Caudium might meet your needs.

    Both are multithreaded web servers, which are very good at producing dynamic content.
    They have a very nice macro language built in (RXML) and support scripts written in the language Pike (which both servers are written in as well). Both also support embedded perl scripts, as well as java servlets, and fastcgi scripts. It also has very good database support, and support for dynamic image generation.

    I haven't used Caudium myself - it is a fork of the Roxen 1.3 codebase, and I had already started using the new 2.x features before the fork happened. It is GPLed, and is available here

    Roxen is available in two forms, a free GPLed version (available here) and a commercial version which includes content management features (Demo available here).

    The new versions of Roxen are bundled with a MySQL install which the server uses for storing configuration data, caching generated images and pike/rxml pcode, and for storing internally managed user databases. It also works well with PostgreSQL as an external database.

    Php support in roxen is a little tricky. Recent versions of PHP can be compiled into a module that can be merged into pike, allowing both Roxen and Caudium to execute PHP scripts inside of the multithreaded main process. This is still buggy under Roxen, but I understand that it works well under Caudium. Personally, I compiled php as a fastcgi, and used Roxen's fastcgi module.

  6. Re:Apache and security by Electrum · · Score: 4, Informative

    When will you stop bitching and join the Apache devel team to help make it secure? When will you submit a non-blocking I/O patch to the Apache codebase?

    Apache can't be made secure for the same reasons that BIND and Sendmail can't be made secure. It needs to be completely rewritten using secure coding practices. You can't just keep fixing security bugs and hope you found them all.

    If you knew anything about Apache's design, then you would know that it's impossible to just add non blocking I/O. The entire server would have to be redesigned. If you read the Apache development list, then you will see that this is never going to happen. The developers don't care. They seem convinced that it is too much work and get upset when anyone mentions the idea of non blocking I/O. There are more than technical issues that need to be solved before Apache can become a better server.

    If you don't like the direction they are going, either don't use it or join the devel team. There's no need to bitch and moan about it like it intimately affects your life.

    So I'm no longer allowed to give my opinion? I thought that was the purpose of this comment forum.

    Apache is NOT the fastest out there...but it is the most configurable (PHP, Perl, etc) and the best all-around webserver there is. Many of us think that the Apache team has done great work and we apprieciate every minute of it.

    Yes, that's exactly my point. It's the best we have and no one seems to care that it could be ten times better. And no, it's not just a matter of a few patches. Apache's design is fundamentally flawed.
  7. Re:Apache and security by MattRog · · Score: 1

    I'm checking out Caudium right now. How does PHP speeds compare from Caudium and Apache? I am also giving Zeus a spin. :D

    --

    Thanks,
    --
    Matt
  8. Re:Apache and security by Electrum · · Score: 2

    Do they use non blocking I/O to serve static content? Even when serving dynamic content, the majority of the requests will be for static content. Therefore, to get the best performance, non blocking I/O must be used. Multithreaded servers have an inherent performance limit. On many UNIX systems, threads are as heavyweight as processes.

  9. Re:Apache and security by Anonymous+Conrad · · Score: 1

    [emphasis mine]
    support scripts written in the language Pike (which both servers are written in as well).

    and Pike, according to the Caudium website, is interpreted.

    What's the point of having non-blocking I/O if you're going to run via an interpreter? Does it really have respectible performance?

  10. Re:Apache and security by Anonymous+Conrad · · Score: 1

    And when will Apache deliver truly high performance by having a non blocking I/O model? 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.

  11. 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.
  12. Re:Apache and security by fredan · · Score: 1

    If you need fast web server which should handle static content, take a look at TUX. Thisone is fast.
    Here can you find some benchmarks that I have done. All test was made on kernel 2.4.18

  13. 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.

  14. Re:Apache and security by thogard · · Score: 1

    I used to run a web server for very well known company that ran a large number of TV ads to get people to hit the server. There were never any preformance problems and it was just apache running on a an ultrasparc box. Most of the content was static or small SSI and a handfull of cgi's. What are people doing where they are complaing about the slow apache is?