Apache HTTP Server

WHO: The Apache Software Foundation (ASF); Apache powers half the Internet, petabytes of data, teraflops of operations, billions of objects, and enhances the lives of countless users and developers. Established in 1999 to shepherd, develop, and ... [More] incubate Open Source innovations "The Apache Way", the ASF oversees 150+ projects led by a volunteer community of over 350 individual Members and 3,000 Committers across six continents. WHAT: The ASF returns to OSCON, providing conference participants and members of the media and analyst community an opportunity to meet with members of the Apache community. Attendees can learn about how the ASF works, and discuss an array of Apache projects, from Abdera to Zookeper. Individuals and activities include: 1) ASF Directors and Officers:- Rich Bowen –ASF Board; Apache HTTP Server; Apache Allura (Incubating)- Shane Curcuru (OSCON presenter) –former ASF Board member; VP ASF Brand Management; Apache Incubator- Ross Gardler –ASF Board; VP Apache Community Development; Apache Incubator- Les Hazlewood –VP Apache Shiro- Leif Hedstrom –VP Apache Traffic Server- Jim Jagielski (OSCON presenter) –ASF President; VP Apache C++ Standard Library; Apache HTTP Server- Sally Khudairi – VP ASF Marketing & Publicity- Mahadev Konar (OSCON presenter) –VP Apache Zookeeper- Arun Murthy (OSCON presenter) –VP Apache Hadoop- Nóirín Plunkett (OSCON presenter) –ASF Executive Vice President- Craig Russell –ASF Secretary; Apache OpenJPA- Greg Stein –ASF Vice Chairman; VP Apache Subversion2) ASF Members and Apache code Committers:- David Geary (OSCON presenter) –Apache Struts- Simon MacDonald (OSCON presenter) –Apache Incubator- Justin Erenkrantz –former ASF President; Apache OODT; Apache Subversion Project Management Committee- Sebastian Bergmann (OSCON presenter) –Apache Incubator- Rasmus Lerdorf (OSCON presenter) –former ASF Board member; Apache HTTP Server Project Management Committee- William Au (OSCON presenter) –Apache Lucene, Apache Solr- Joe Bowser (OSCON presenter) – Apache Incubator- Bastian Hofmann (OSCON presenter)  –Apache Shindig Project Management Committee- Brian LeRoux (OSCON presenter) –Apache DeviceMap (Incubating)- William A. Rowe Jr. –former ASF Board member; Apache HTTP Server; Apache Tomcat- Danese Cooper –Apache Incubator Project Management Committee- Jeffrey Taylor Potts –Apache Chemistry Project Management Committee- Lennard de Rijk –Apache Wave (Incubating)- Edward J. Yoon –Apache Bigtop (Incubating); Apache Hama (Incubating) Project Management Committee- Dan Allen –Apache DeltaSpike (Incubating)- Matthew Franklin –Apache Incubator Project Management Committee; Apache Rave- Ryan Baxter –Apache Shindig Project Management Committee- David Nalley –Apache Incubator- Kevin Kluge –Apache Incubator3) Pre-conference Hackathons, BarCamps, Talks, and MeetUps on various Apache Top-Level and Incubating Projects, including:- Social & Widgets: Apache Wave (Incubating); Apache Rave; Apache Shindig- Big Data & Content: Apache Chemistry; Apache Hama (Incubating)- Cloud  & Web Infrastructure: Apache Traffic Server; Apache CloudStack (Incubating); Apache Shiro;  Apache HTTP Server Documentation- Programming & Productivity: Apache OpenOffice (Incubating); Apache DeltaSpike (Incubating)WHEN: Pre-conference Hackathons, BarCamps, Talks, and MeetUps - Monday 16 July –Social & Widgets; Big Data & Content- Tuesday 17 July –Cloud & Web Infrastructure; Programming & Productivity Birds of a Feather- Thursday 19 July –Apache Allura (Incubating) Expo Hall- Tuesday 16 July –Opening Reception 5-6PM- Wednesday 17 July –10AM-4.30PM; Booth Crawl 5.40-7PM- Thursday 18 July –10AM-5PM (Expo close) To view the complete OSCON schedule, visit http://www.oscon.com/WHERE: OSCON –Oregon Convention Center, Portland Pre-conference Hackathons, BarCamps, Talks, MeetUps, and BoFs: Location TBA Expo: Hall D- Apache Software Foundation - Booth #910- Apache CloudStack - Booth #217 –sponsored by Citrix- Apache Shiro - Booth #423 –sponsored by StormpathAbout The Apache Software Foundation (ASF)Established in 1999, the all-volunteer Foundation oversees nearly one hundred fifty leading Open Source projects, including Apache HTTP Server — the world's most popular Web server software. Through the ASF's meritocratic process known as "The Apache Way," more than 400 individual Members and 3,500 Committers successfully collaborate to develop freely available enterprise-grade software, benefiting millions of users worldwide: thousands of software solutions are distributed under the Apache License; and the community actively participates in ASF mailing lists, mentoring initiatives, and ApacheCon, the Foundation's official user conference, trainings, and expo. The ASF is a US 501(3)(c) not-for-profit charity, funded by individual donations and corporate sponsors including AMD, Basis Technology, Citrix, Cloudera, Facebook, GoDaddy, Google, IBM, HP, Hortonworks, Huawei, Matt Mullenweg, Microsoft, PSW Group, SpringSource, and Yahoo!. For more information, visit http://www.apache.org/. "Apache", "Abdera", "Apache Abdera", "Apache Allura", "Apache BigTop", "Apache C++ Standard Library", "Apache Chemistry", "Apache CloudStack", "Apache DeltaSpike", "Apache DeviceMap", "Apache Hadoop", "Apache HTTP Server", "Apache Incubator", "Lucene", "Apache Lucene", "OODT", "Apache OODT", "Apache OpenJPA", "Shindig", "Apache Shindig", "Shiro", "Apache Shiro", "Solr", "Apache Solr", "Struts", "Apache Struts", "Subversion", "Apache Subversion", "Tomcat", "Apache Tomcat", "Traffic Server", "Apache Traffic Server", "Apache Wave", "Apache Zookeeper", and "ApacheCon" are trademarks of The Apache Software Foundation. All other brands and trademarks are the property of their respective owners. For more information, contact:Sally KhudairiVice PresidentThe Apache Software [email protected]+1 617 921 8656 # # # [Less]

Two new features have recently been added to the CMS, courtesy of David Blevins.  These features are geared towards streamlining the user experience for anonymous users.  The first feature is "Quick Mail", which is the analog of "Quick Commit" but ... [More] for anonymous users who cannot otherwise commit their changes directly.  Quick Mail, which is enabled by default, will take the immediate submission of an anonymous Edit session and post it directly to the project's dev list, saving several steps that might be hard for a new user to walk through. The second feature is a natural result of that known as anonymous clones.  In the subsequent mailout from "Quick Mail", there will be an url for committers to use to effectively clone the working copy of the anonymous user who generated the patch.  This makes review and subsequent commit operations much more convenient than directly applying the emailed patch to a local working copy.  In fact it is possible for users to clone a non-anonymous user's working copy, so anyone experiencing chronic problems with their working copy on the CMS can get help from other committers by simply using the "Mail Diff" feature to contact either the dev list or another apache committer with details of their problem. We have added these features in the hopes this will considerably lower the bar for anonymous users in particular to take advantage of the CMS.  Please let your community know about them! [Less]

Highly-Performant Cloud Computing Service Serves Dynamic Content, Billions of Objects, and Terrabytes of Data for Large-Scale Deployments in Use at Akamai, Comcast, GoDaddy, LinkedIn, Yahoo!, and More. WHO: The Apache Software Foundation (ASF). ... [More] Recognized as one of the most compelling communities in Open Source for shepherding, developing, and incubating innovations "The Apache Way", the ASF is responsible for millions of lines of code overseen by an all-volunteer community across six continents. Apache technologies power more than half the Internet, petabytes of data, teraflops of operations, billions of objects, and enhance the lives of countless users and developers. WHAT: Apache Traffic Server v3.2.0, the Cloud Computing "edge" service able to handle requests in and out of the Cloud by a) serving static content (images, JavaScript, CSS, and HTML files), and b) routing requests for dynamic content to a Web server (such as the Apache HTTP Server). V3.2.0 is the Project's latest stable release. Key highlights include: - Over 800 commits, and 300 JIRA tickets closed since v3.0. - Several SSL improvements, including SNI (Server Name Indication) and NPN (Next Protocol Negotiation). Overall SSL stability is also improved. - Full IPv6 support, v3.0 only had client side IPv6. All IP related plugin APIs are now also IPv6 aware. - New, flexible configurations for managing inbound and outgoing IP addresses and ports. You can now bind any number, and combinations, of addresses and ports for both HTTP and HTTPS. - Range request for large objects in cache are now much (*much*) faster. - Several new, and improved, plugin APIs are now available. - Performance and stability improvements in the Cluster Cache feature. - Much better performance when proxying to a Keep-Alive HTTP backend server connection. Overall cache performance is also significantly better. - Several stable plugins are now included with the core distributions. - Supports all gcc versions 4.1.2 and higher, Clang / LLVM 3, and the Intel compiler suite. Apache Traffic Server software is released under the Apache License v2.0, and is overseen by a self-selected team of active contributors to the project. A Project Management Committee (PMC) guides the Project's day-to-day operations, including community development and product releases. For more information, including documentation, mailing lists, and related resources, please visit http://trafficserver.apache.org/. WHERE: Download Apache Traffic Server v3.2.0 at http://trafficserver.apache.org/downloads. ABOUT THE APACHE SOFTWARE FOUNDATION (ASF): Established in 1999, the all-volunteer Foundation oversees nearly one hundred fifty leading Open Source projects, including Apache HTTP Server — the world's most popular Web server software. Through the ASF's meritocratic process known as "The Apache Way," more than 400 individual Members and 3,500 Committers successfully collaborate to develop freely available enterprise-grade software, benefiting millions of users worldwide: thousands of software solutions are distributed under the Apache License; and the community actively participates in ASF mailing lists, mentoring initiatives, and ApacheCon, the Foundation's official user conference, trainings, and expo. The ASF is a US 501(3)(c) not-for-profit charity, funded by individual donations and corporate sponsors including AMD, Basis Technology, Citrix, Cloudera, Facebook, GoDaddy, Google, IBM, HP, Hortonworks, Huawei, Matt Mullenweg, Microsoft, PSW Group, SpringSource, and Yahoo!. For more information, visit http://www.apache.org/. "Apache", "Traffic Server", "Apache Traffic Server", and "ApacheCon" are trademarks of The Apache Software Foundation. All other brands and trademarks are the property of their respective owners. # # # [Less]

The Apache log4net team would like to welcome Dominik Psenner as a new committer! Welcome!

Sometime last night the 5 millionth copy of Apache OpenOffice 3.4 was downloaded.   Over 5 million downloads in 6 weeks.   To put this in perspective, the population of Norway just hit 5 million earlier this year.  That's a lot of OpenOffice! ... [More] If you look at a chart of our daily download numbers you see that the download rate has increased in the past two weeks.  This is caused by our recent enabling of the update notification server.   Installations of the previous version of OpenOffice, version 3.3.0, check our servers once a week to see if a new version of OpenOffice is available.   So we're now getting a mix of new installs and upgrade installs. So what are we doing in the project other than counting download numbers?  Quite a lot, in fact.   Many are working on a 3.4.1 maintenance release.   This release will focus on quality (bug fixes) rather than new features.  It will also include new translations, likely including UK English, Finnish and Slovenian.  Work on other translations is underway, based on volunteer interest, including Uyghur.   We're tracking the 3.4.1 items on the wiki, if you want to see the details.  Tentative date for 3.4.1 is the end of July. In parallel with the 3.4.1 maintenance branch we're also working on discussing how best to use the Symphony contribution from IBM.  This code has many bug fixes and UI enhancements that could benefit OpenOffice users.  Some of the bug fixes from Symphony have already made it into the 3.4.1 branch.  For post-3.4.1, we are weighing two options: a slower, incremental merge of Symphony enhancements into OpenOffice, or more rapid rebasing of OpenOffice on top of Symphony.  Each option has its advantages and disadvantages, as well its supporters.  The Apache OpenOffice project welcomes new volunteers on these and other items.  Developers are needed, of course, but also those interested in testing, technical writing, translation, web design, usability, marketing, event planning, system admins, etc.  This is a large, high visibility project where we can really make an impact in the world, but also one that is non-bureaucratic and organizationally flat, where it is easy for newbies to fit in.   It is a great place to get started on an open source project.  If you are interested in volunteering, you can send an email to our public mailing list, at ooo-dev-AT-incubator.apache-DOT-org.   Introduce yourself and tell us what you would be interested in doing. More information on the Apache OpenOffice product, including info on how to download, can be found at our website, www.openoffice.org. To be added to a mailing list for official OpenOffice-related announcements, send an email to ooo-announce-subscribe-AT-incubator.apache.org. You can also follow us on Facebook, Twitter, Identi.ca and Google . [Less]

The Swiss company Adfinis SyGroup is active in the Apache OpenOffice project, contributing the Solaris build, as well hosting an OpenGrok index of the OpenOffice source code.   The following interview was conducted via email ... [More] between PMC member Rob Weir (R) and Nicolas Christener of Adfinis SyGroup (N). R: Please tell our readers a little about yourself and Adfinis SyGroup. N: Adfinis SyGroup AG was founded a few months ago as a result of the merge of the two companies (Adfinis and SyGroup). We have two offices in Switzerland (one in Berne and one in Basel) and around 35 employees whereof most of them are engineers. We strongly focus on services around OpenSource technologies and have two departments. The system engineering team builds and operates server and services built on Linux/Unix and the software team develops/customizes applications based on OpenSource. Currently we have five people involved in our work on Apache OpenOffice: David, Denis, Hans, Nicolas and Matthias. (In the above photograph, from left to right are: Nicolas, Denis, Hans, Matthias, Dave) R: What got you interested in Apache OpenOffice?  Were you involved at all in OpenOffice.org previously? N: I started to build OpenOffice.org packages for the Paldo Linux distribution a few years ago and acquired a decent knowledge about the needed steps to get a proper OOo build. This involvement enabled us to make contacts in the OpenOffice community in Switzerland and concluded our first contracts for OOo consulting and engineering. Oracle's end-of-support for OOo enabled us to step in and provide services and support for other customers as well. R: Describe some of the technical work you did to get a successful Solaris port of Apache OpenOffice 3.4? N: As the previous builds on Solaris were mostly done by Sun and Oracle the information about this topic were quite sparse. For example, we did not know the exact compiler which was used, we didn't know what flavor of Solaris was used, and it seemed that the people who knew those things disappeared. We decided to start with the latest OOo version, which was released on Solaris, because we knew that this one is buildable on Solaris. With the knowledge we gained during this process, we took a stab at the development version of AOO 3.4 and got a working build quite fast, which was very motivating. Most of the build breakers could be solved by patching the build system (only one modification in the code). As one of our customers uses 3rd-party binary extensions we were concerned to maintain ABI compatibility - therefore we used the SolarisStudio compilers for our work. After we delivered a first build to our customer, they reported two major bugs which we had to fix in order to make a deployment on their system possible. It took us some time to find proper solutions for those bugs, but thanks to the great support by the community we were able to fix them and build a new version which seems to work as expected. Finding suitable SPARC hardware is a bit of an issue too. Our current machine runs OpenSolaris 2009.06 - we hope to get better hardware soon which would also be capable of running Solaris 11. R: What items remain before it is complete? N: We are currently in the QA phase and wait for a final feedback from our customer. As soon as our customer decides that the build can be used for deployment (>200 workstations, many documents with several hundred or even over thousand pages, Writer is one of the most essential tool in their daily work-flow) we will build AOO 3.4 for all languages and if possible also as Solaris packages (*.pkg). We'll make those builds available for free download and try to do this upcoming versions as well. It is important to us that the Solaris SPARC build stays well maintained. Therefore we'd like to have a continuous/nightly build, where developers can check the build logs in order to see whether their latest check-in works on Solaris SPARC. We are working on providing an official build bot for the project. R: If someone wants to help test this port, where can they find it? We upload all our builds to our website: http://adfinis-sygroup.ch/aoo-solaris-sparc http://adfinis-sygroup.ch/aoo-solaris-x86 We are also interested in creating official community builds for AOO and would be glad to talk about such opportunities. R: Do you have maybe top three tips for Linux application developers, on things to be careful about, if they want their applications to be more portable? N: Especially concerning AOO we would like to point out that many large companies/organizations use software in their data-center (i.e., for thin-clients). In such an environment Solaris/SPARC is still a big player and a great many users depend on well-maintained ports. Therefore these deployments/technologies concern all developers and we encourage everyone to keep in mind: There are other processors than Intel. There are other operating systems than Windows/Linux/OS X. There are other tool chains than GNU. Buildbots are a great help to keep up this awareness. Thank you very much for the interview! We would also like to thank Raphael Bircher for his continuous support and the whole community which does a great job in delivering a high quality office productivity suite. [Less]

Consider the following snippet taken from a live CGI script running on the host that serves www.apache.org: #!/usr/bin/perl use strict; use warnings; print "Content-Type: text/html\n\n"; my $artifact = "/apache-tomee/1.0.1-SNAPSHOT/"; ... [More] $artifact = $ENV{PATH_INFO} if $ENV{PATH_INFO}; $artifact = "/$artifact/"; $artifact =~ s,/+,/,g; $artifact =~ s,[^a-zA-Z.[0-9]-],,g; $artifact =~ s,\.\./,,g; my $content = `wget -q -O - http://repository.apache.org/snapshots/org/apache/openejb$artifact`; ... Looks pretty good right?  Any questionable characters are removed from $artifact before exposing it to the shell via backticks... hmm, well turns out that's not so easy to determine. The first warning sign that was given to the author of this script was that he hadn't enabled taint checks- if he had this is how things probably would have looked: #!/usr/bin/perl -T use strict; use warnings; print "Content-Type: text/html\n\n"; my $artifact = "/apache-tomee/1.0.1-SNAPSHOT/"; $artifact = $ENV{PATH_INFO} if $ENV{PATH_INFO}; $artifact = "/$artifact/"; $artifact =~ s,/+,/,g; $artifact =~ m,^([a-zA-Z.[0-9]-]*)$, or die "Detainting regexp failed!"; $artifact = $1; $artifact =~ s,\.\./,,g; my $content = `wget -q -O - http://repository.apache.org/snapshots/org/apache/openejb$artifact`; ... Which doesn't look like much of a change, but the impact on the actual logic is massive: we've gone from a substitution that strips unwanted chars to a fully-anchored pattern that matches only a string full of wanted chars only, and dies on pattern match failure.  Sadly the developer in question did not heed this early advice. As it turns out, there is a bug (well several) in the core pattern that renders the original substitution ineffective.  However the impact on the taint-checked version causes the detainting match to fail and renders the script harmless!  The practical difference is that instead of a script with a working remote shell exploit, we have script that serves no useful purpose.  To the Apache sysadmins this is a superior outcome, even though to the developer the original, essentially working script is preferable- worlds are colliding here, but guess who wins? At the ASF the sysadmins almost invariably refuse to run perl or ruby CGI scripts without taint-checking enabled, and will always prefer CGI scripts be written in languages that support taint checks as they tend to enforce good practice in dealing with untrusted input.  This example, which is in fact one of the first times we've even considered allowing Apache devs to deploy non-download CGI scripts on the www.apache.org  server, serves as a useful reminder to Apache devs as to why using languages that support taint checks is an essential component of scripting on the web. [Less]

If you download Apache OpenOffice 3.4, or browse our website, you will notice that we have a rebranding effort underway.    I'd like to offer a few thoughts on what happened, why and what will be coming next. When the OpenOffice.org project came ... [More] to Apache, it started in the Apache Incubator, where all projects new to Apache start.  Here we worked on various tasks to integrate the project into Apache, from licensing, policy, process and cultural perspectives.    Previous posts have discussed the site migration work and the IP review/cleanup tasks.  Another task for the community was to adapt to the Apache branding policy. Apache projects, under the umbrella of the Apache Software Foundation, share a common website, a common license, and are part of a common larger community of developers and users.  To reinforce this, all Apache projects, and their products, use the naming pattern "Apache ___", such as Apache Hadoop, Apache Subversion, Apache POI, etc. Possible conforming names that the community discussed and considered included: Apache Open Office Apache OpenOffice Apache OpenOffice.org Apache ODF Office  A vote was held, and "Apache OpenOffice" won.  A new logo, based on a design by Michael Acevedo, was selected, and that is what you see our website now. Former OpenOffice.org logo New Apache OpenOffice logo Updating the website and the code to use this new branding will take some time.   The Apache OpenOffice 3.4 release, for example, still has some places where it refers to "OpenOffice.org".  We hope to have this rebranding completed in our next major release. Note: You will still continue to see references to OpenOffice.org in the context of older release.  For version 3.3.0 and earlier it is still proper to refer to them as OpenOffice.org, since they are pre-Apache.  But all new work at Apache will use the name Apache OpenOffice. [Less]

Last week, internal audit activity discovered that the access logs of some committer-only Apache services contained passwords but had been available to every Apache committer. The problem The httpd logs of several ASF services are ... [More] aggregated and archived on minotaur.apache.org.  Minotaur is also people.apache.org, the shell host for committers, and committers were encouraged to analyse the logs and produce aggregated data.However, for two services, the archived logs included forensic logs, which are extra-verbose logs that include all HTTP request headers.  (The logs are never encrypted, even if the HTTP connection was wrapped by SSL encryption.)  Both of these services --- http://s.apache.org and http://svn.apache.org --- allow anyone to use them in a read-only manner anonymously, and allow further operations (such as creating shortlinks) to LDAP-authenticated committers.  Authentication is usually done by embedding the username and password, encoded in base64, in the "Authorization:" HTTP header, under SSL encryption.Base64 is a reversible transform.  (It is an encoding, not a cipher.)Consequently, any Apache committer could learn the passwords of any other committer by reading the log files and reversing the base64 encoding. Shutting the barn door The logs archive directory was made readable by the root user only.  Forensic logging was disabled, and past forensic logs deleted.  ZFS snapshots containing those logs were destroyed, too. Finding the horse We know that several committers had on one occasion or another copied the logs in order to analyse them, so we operated on the assumption that copies of the sensitive forensic logs were circulating on hardware we do not control.  We therefore opted to have all passwords changed, or reset.Several Apache committers whose passwords grant very high access were advised privately to change their passwords.  The root@ team ensured the follow-through and, before announcing the vulnerability any further, changed the passwords of those whom had not done so themselves.  The root@ team also changed the passwords of all non-human (role) accounts on those services.The vulnerability was then announced to all Apache committers with the same instructions: 'Your passwords may be compromised; change them "now"; we will explain the problem later.'.  This notice was authenticated via a PGP signature and via acknowledging it in a root-owned file on people.apache.org.Finally, passwords that have not been changed after forensic logs had been disabled --- and, therefore, were presumed to be contained in compromised forensic logs --- were changed by the root@ team to random strings. Implications Were some committer to have compromised another Apache account using this vulnerability prior to these steps being taken, note that root access to all apache.org hosts is only available using one-time-passwords (otp) for certain privileged sudo users.  Such account holders have been instructed not to use the same password for otp as for LDAP, so this would not have resulted in an attacker gaining root privileges without our knowledge.  All of our commit activity is peer-reviewed and logged to various commit lists, and no reports of unusual commit activity have been received during the time frame in which this exposure was effective.  In fact no unusual activity has ever been reported regarding any of our LDAP-based services, so there is no reason for us to suspect malicious activity has occurred as a result of this vulnerability. Preventing recurrence No code changes were needed to the software that s.apache.org and svn.apache.org run; the software was behaving correctly according to its configuration, but the configuration itself --- and the in-house log archiving scripts --- were incorrect.A member of the infrastructure team will be approaching the Apache HTTPD PMC with a documentation patch for mod_log_forensic. Epilogue There were no malicious parties involved here (to our knowledge); we just made a configuration error.  The nature of the error meant we had to assume all passwords were compromised, and that was costly to fix.We hope our disclosure has been as open as possible and true to the ASF spirit.  Hopefully others can learn from our mistakes.  See our prior incident reports from the Apache Infrastructure Team.Committers --- please address questions to [email protected] only.Queries from the press should be sent to [email protected] hacking! [Less]

The Apache Logging team is pleased to announce the Apache log4j 1.2.17 release! Apache log4j is a wellknown framework for logging application behaviour. This is release is a maintenance release containing these issues: log4j 1.2.17 release ... [More] preparation Fixes 49470. Configure from an InputStream Fixes 52913. JDBCAppender not closed due to SQL Exception while executing an SQL (thanks to Anurag Agarwal) Fixes 51597. Memoryleak - org.apache.log4j.helpers.ThreadLocalMap Fixes 50486. DOMConfigurator does not close input stream when configured based on URL. Fixes 48588. javadoc.jar was missing NOTICE and LICENSE and contained .svn entries. Fixes 49078. Wrong log levels logged with serialized LoggingEvent. Fixes 50238. Add org.apache.log4j.rewrite.RewriteAppender and org.apache.log4j.util.UtilLoggingLevel from discontinued receivers companion. Fixes 51766. Details: http://logging.apache.org/log4j/1.2/changes-report.html#a1.2.17 Apache log4j 1.2.17 requires JDK 1.4 or later. [Less]