This is a general call-to-arms for everyone who uses log4net as their logging solution. If log4net is the logging framework that you are using and would like to keep using in the future it is time now to get involved. The project needs a larger developing community to move on! We really need more people who want to shape the future of log4net at the Apache Software Foundation.

In all the time since log4net has been started by Nicko Cadell more than ten years ago, there have never been more than two or three people regularly contributing to it. As is normal in open source projects people have come and gone when their interests or just the amount of time they could invest have changed.

At the moment Dominik Psenner and Stefan Bodewig are the only people semi-actively working on log4net and neither of them is able to devote as much time to the project as they'd like to and as would be required.

Realistically log4net is maintenance mode where development of new features is not going to happen.

This has repeatedly made log4net lag behind recent developments in the .NET world. It took a long time to get a version out that properly worked with .NET 4.0 in 2011 and adaptions to .NET 4.5 also took much longer than many users would have wished. We are seeing it again with .NET Core right now. In addition there are many unresolved issues in log4net's JIRA.

Despite this there are more than 2500 downloads of the logging framework every day from nuget. We are asking you, the log4net community, to get your hands dirty.

Right now we are in the process of creating a log4net release that works for .NET Core. It is a very targeted effort and it is very unlikely Dominik and Stefan will be able to contribute more in the future than we did during the past months.

If you are willing to help, please join log4net's dev mailing list and raise your hand. Look through log4net's issue tracker and pick things you'd like to work on. If you don't know where to start, please ask, Dominik and Stefan will be there to help.

If there is anything holding you back from contributing, let's discuss it and get it out of the way. Nothing is carved into stone, neither what the future of log4net holds nor how we make it happen.

Links

log4net's JIRA
https://issues.apache.org/jira/browse/LOG4NET
dev mailing list
https://logging.apache.org/log4net/mail-lists.html
How the ASF works
https://www.apache.org/foundation/how-it-works.html, https://www.apache.org/dev/contributors.html

path: /en/Apache/Log4Net | # | Writebacks

In case you have missed it, there is a flaw in the code that writes bzip2 archives in both Ant and Commons Compress. There are new releases for both of them, so go grab them: Ant, Commons Compress.

As part of the process of creating bzip2 compressed blocks the input data (usually in chunks of 900kb) is sorted (during the Burrows-Wheeler transformation, if you want to know). The only sorting algorithm present in the bzip2 classes prior to the security release is very efficient for the average case but shows extraordinarily bad performance for very repetitive inputs. For certain inputs the bzip2 task took two hours on my really fast work notebook (at 100% CPU for a single core) while it finishes in less than two seconds with Ant 1.8.4.

These inputs have to be specially crafted, it is very unlikely you will face them in the wild. The flaw turns into a security issue if you are providing a public service that compresses input created by arbitrary users - maybe a public build server or an archiving solution.

The bzip2 code in Ant (and all forks that stem from it, like Commons Compress) was derived from an early version of Julian Seward's libbzip2. Starting with 0.9.5 libbzip2 detects if sorting is taking too long because of bad inputs and switches to a different sorting strategy in such cases. The fix in the two releases now consists of porting this fallback sorting algorithm from C to Java.

While porting this I learned a lot. I read several academic papers in order to understand what was actually going on. It felt like I was back in University again and it felt good.

Many thanks to David Jorm of the Redhat Security Team who uncovered the issue.

path: /en/Apache/Ant | # | Writebacks

yesterday we released Ant 1.8.3, go grab it from the download page. By pure coincidence it was released on a leap-day.

This release really mostly is a bug fix release, see the release notes for a complete list. There isnt anything major sticking out to me, but I know people have been bitten by some of the bugs - like forked Java processes hanging when they read from System.in - so for them the new release was important.

The dev team has decided to drop Java 1.4 support (as Ant's runtime) for trunk, so this may likely be the last release supporting Java 1.4. We have prepared a branch so we may be able to create more 1.8.x releases if a major bug raises its head. For trunk this means we'll be able to start using "modern" features like generics. It also means I can merge some improvements like Zip64 support from Commons Compress into Ant.

One of the fixes introduced a new class in order to better multiplex between System.out and System.err when forking a new process. This allows Ant 1.8.3 to be detected by either

  <antversion property="Ant-1.8.3-or-later"
              atleast="1.8.3"/>

or

  <available property="Ant-1.8.3-or-later"
             classname="org.apache.tools.ant.util.LineOrientedOutputStreamRedirector"/>

It's been the first time I acted as Ant's release manager since Ant 1.1 more than eleven years ago, quite a bit has changed WRT process but also automation since then. It wasn't as painful as I feared it to be, largely because we no longer ship optional tasks that require third party jars that cannot be downloaded freely.

path: /en/Apache/Ant | # | Writebacks

A few days after Apache Commons Compress 1.3 has been released the Compress Antlib has seen a new release as well. This gives Ant support for Zip64 extensions, the Unix dump format (read-only) and the Pack200 format.

Prior to this release Pack200 support has already been available via a a task at java.net but the Compress Antlib also adds a pack200resource as well as a pack200normalize task that can be used to "normalize" a JAR so that it can be signed, packed and unpacked with the signature remaining valid.

path: /en/Apache/Ant | # | Writebacks

The last log4net release already stopped supporting Compact Framework 1.x and the Shared Source CLI as part of the binary distributions - but versions for them are still buildable from source. In order to figure out what platforms we will need to support in future releases the team is asking log4net's users to participate in a small survey.

Rather than repeating Roy's whole mail, here is the original announcement.

path: /en/Apache/Log4Net | # | Writebacks