Re: [VOTE] Release Apache Log4j 2.12.3-rc1

+1 Remko On Tue, Dec 21, 2021 at 12:52 PM Carter Kozak wrote: > +1 > > -ck > > > On Dec 20, 2021, at 22:46, Matt Sicker wrote: > > > > +1 > > > > Notes on the release: > > * Sigs and checksums good > > * Builds and tests fine > > * Outdated copyright year in NOTICE.txt > > > > -- > > Matt Sick

Re: [logging-log4j2] 01/01: [DOC] Fix log4j-2.3.x About page incorrect security.html anchor links

Thank you Gary! Great catch! On Tue, Dec 21, 2021 at 11:51 AM Gary Gregory wrote: > I'm not sure this is the right branch, I think log4j-2.3.x is the > right one. > > Ralph? > > Gary > > On Mon, Dec 20, 2021, 21:33 wrote: > > > This is an automated email from the ASF dual-hosted git repository.

[VOTE] Release Apache Log4j 2.3.1-rc1 for Java 6

This is a vote to release Log4j 2.3.1, a security release for Java 6 users. Please download, test, and cast your votes on the log4j developers list. [] +1, release the artifacts [] -1, don't release because... The vote will remain open for as short amount as time as required to vet the release.

[VOTE] Release Log4j Kotlin API 1.2.0-rc3

This is a vote to release Log4j Kotlin API version 1.2.0, the next version of the Kotlin facade for Log4j2. Please download, test, and cast your votes on the log4j developers list. [] +1, release the artifacts [] -1, don't release because... The vote will remain open for 24 hours (or more if req

Re: [VOTE] Release Apache Log4j 2.12.3-rc1

+1 -ck > On Dec 20, 2021, at 22:46, Matt Sicker wrote: > > +1 > > Notes on the release: > * Sigs and checksums good > * Builds and tests fine > * Outdated copyright year in NOTICE.txt > > -- > Matt Sicker > >> On Dec 20, 2021, at 18:52, Ralph Goers wrote: >> >> This is a vote to release L

Re: [VOTE] Release Apache Log4j 2.12.3-rc1

There was a bug in the site build. I checked the fix in to the branch. It doesn’t matter for the release. Ralph > On Dec 20, 2021, at 6:46 PM, Gary Gregory wrote: > > Building from the git tag for HEAD detached at log4j-2.12.3-rc1 (2b9359b23) > > - mvn apache-rat:check -DskipTests OK > - mvn

Re: [VOTE] Release Apache Log4j 2.12.3-rc1

+1 Notes on the release: * Sigs and checksums good * Builds and tests fine * Outdated copyright year in NOTICE.txt -- Matt Sicker > On Dec 20, 2021, at 18:52, Ralph Goers wrote: > > This is a vote to release Log4j 2.12.3, a security release for Java 7 users. > > Please download, test, and cas

Re: [VOTE] Release Log4j Kotlin API 1.2.0-rc2

I fixed some rat errors, but yeah, looks like I missed that. I’ll cancel this and roll a third RC. — Matt Sicker > On Dec 20, 2021, at 20:43, Raman Gupta wrote: > > As far as I can tell nothing has changed? Did you mean to point to 2.17.0? > >> On Sun, Dec 19, 2021 at 5:52 PM Matt Sicker wr

Re: [logging-log4j2] 01/01: [DOC] Fix log4j-2.3.x About page incorrect security.html anchor links

I'm not sure this is the right branch, I think log4j-2.3.x is the right one. Ralph? Gary On Mon, Dec 20, 2021, 21:33 wrote: > This is an automated email from the ASF dual-hosted git repository. > > rpopma pushed a commit to branch java6 > in repository https://gitbox.apache.org/repos/asf/loggi

Re: [VOTE] Release Log4j Kotlin API 1.2.0-rc2

As far as I can tell nothing has changed? Did you mean to point to 2.17.0? On Sun, Dec 19, 2021 at 5:52 PM Matt Sicker wrote: > This is a vote to release Log4j Kotlin API version 1.2.0, the next version > of the Kotlin facade for Log4j2. > > Please download, test, and cast your votes on the log4

Broken CI

After getting https://github.com/apache/logging-log4j2/pull/646 in what I think is a good state, I have no idea if it is safe or not to merge because the 1st build GitHub shows is red: https://github.com/apache/logging-log4j2/runs/4589771553?check_suite_focus=true I don't use GH actions the way we

Re: [VOTE] Release Apache Log4j 2.12.3-rc1

Building from the git tag for HEAD detached at log4j-2.12.3-rc1 (2b9359b23) - mvn apache-rat:check -DskipTests OK - mvn clean install OK except a JVM crash I always get in the Cassandra module tests, just like always. - mvn site -DskipTests fails with: [ERROR] Failed to execute goal org.apache.ma

[VOTE] Release Apache Log4j 2.12.3-rc1

This is a vote to release Log4j 2.12.3, a security release for Java 7 users. Please download, test, and cast your votes on the log4j developers list. [] +1, release the artifacts [] -1, don't release because... The vote will remain open for as short amount as time as required to vet the release.

Re: Couldn't build release branch without reverting the 2.17.1-SNAPSHOT naming commit

You need to run "mvn install" to get the build to work properly locally. This is due to some overlapping Maven hackery to bundle Java 9+ code back into the Java 8 code. On Mon, Dec 20, 2021 at 4:00 PM Dan Kegel wrote: > > I guess this is expected, but on my 2nd machine, I couldn't build the > rel

Couldn't build release branch without reverting the 2.17.1-SNAPSHOT naming commit

I guess this is expected, but on my 2nd machine, I couldn't build the release branch because it couldn't find 2.17.1-SNAPSHOT stuff: [ERROR] Failed to execute goal on project log4j-1.2-api: Could not resolve dependencies for project org.apache.logging.log4j:log4j-1.2-api:jar:2.17.1-SNAPSHOT: org.a

Re: Configuration element for system properties

It is not a typo. We may be missing documentation. I’ll have to search and see. Ralph > On Dec 20, 2021, at 1:18 PM, Gary Gregory wrote: > > Our page > https://logging.apache.org/log4j/2.x/manual/configuration.html#SystemProperties > documents log4j2.component.properties, but you talk about >

Re: Configuration element for system properties

Our page https://logging.apache.org/log4j/2.x/manual/configuration.html#SystemProperties documents log4j2.component.properties, but you talk about log4j2.system.properties. Is that a typo or are we missing documentation? Gary On Mon, Dec 20, 2021 at 3:12 PM Ralph Goers wrote: > > This proposal

Re: Configuration element for system properties

This proposal is problematic. By the time this happens it is possible it is too late for some system properties to do any good. I implemented support for system properties already. I had a need for it for the Spring support. Just put the properties in log4j2.system.properties. PropertiesUtil p

Re: Resurrecting log4j 1.x

Is https://github.com/apache/log4j a mirror of an SVN repo? Gary On Mon, Dec 20, 2021 at 2:31 PM Carter Kozak wrote: > > Same, git migration makes sense to me if we are fixing CVEs. > > -ck > > > On Dec 20, 2021, at 14:28, Matt Sicker wrote: > > > > Sorry, I forgot to vote explicitly. I'd be +

Re: Configuration element for system properties

This one; log4j2.component.properties. That's good indeed, as of now, our tooling is not something I can easily update to generate a new file that then gets propagated to the right place. But it is "simple" to add another entry to an existing file. Not something Log4j needs to worry about of cours

Re: Resurrecting log4j 1.x

Same, git migration makes sense to me if we are fixing CVEs. -ck > On Dec 20, 2021, at 14:28, Matt Sicker wrote: > > Sorry, I forgot to vote explicitly. I'd be +1 on the git repo > migration, but I was also iffy on enabling issues there. > >> On Mon, Dec 20, 2021 at 1:23 PM Vladimir Sitnikov

Re: Resurrecting log4j 1.x

Sorry, I forgot to vote explicitly. I'd be +1 on the git repo migration, but I was also iffy on enabling issues there. On Mon, Dec 20, 2021 at 1:23 PM Vladimir Sitnikov wrote: > > Ralph>I have no problem doing stuff on GitHub > > Bingo! > That is what I said earlier. > > It is really really demot

Re: Configuration element for system properties

Without additional refactoring, the only way this would work is if the logging config is the only config in the application. System properties are global to the JVM. There's already a properties file you can include that gets loaded as a log4j2 system properties file, by the way. On Mon, Dec 20, 2

Re: Resurrecting log4j 1.x

Ralph>I have no problem doing stuff on GitHub Bingo! That is what I said earlier. It is really really demotivating that "PMC is not against". I suggested the move. Neither Ralph nor Matt welcomed the change with +1. At no time do I request you to perform the Git migration. At no time do I reques

Configuration element for system properties

Hello, I'd like to propose that we add an element called SystemProperty to our configuration. This would look like our current Property element but would set a system property instead of a configuration property. My use case is, at work, our tooling generates one XML configuration file for a user

Re: Resurrecting log4j 1.x

I have no problem doing stuff on GitHub. Creating a repo is easy. But someone needs to migrate it from SVN and I don’t have the time for that. If someone puts up a repo at GitHub with all the history I’d be happy to create it under the logging project. Ralph > On Dec 20, 2021, at 12:08 PM, V

Re: Resurrecting log4j 1.x

Matt>I'm not against applying patches to the svn repo, either. How about pull requests at GitHub? Vladimir

Re: Resurrecting log4j 1.x

I'm not against applying patches to the svn repo, either. I haven't forgotten how to use svn as I still use it for Secretary stuff (plus where we put release artifacts). Given that a PMC member would need to do part of the release anyways, that hopefully isn't a blocker. I'm +1 for making a minima

SocketAppenderReconnectTest still flaky on mac 11.8.1; raising timeout to 15 sec helps

My build procedure for the release-2.x branch succeeded on mac 10.16.7, but is failing one lousy test on mac 11.8.1: SocketAppenderReconnectTest.reconnect_should_fallback_when_there_are_multiple_resolved_hosts:129->verifyLoggingSuccess:192->awaitUntilSucceeds:219 » ConditionTimeout I think https:

Re: Resurrecting log4j 1.x

Dear Vladimir, > When it comes to code-related changes, the reviews are vague, and it is > really hard (impossible?) to find consensus. I somehow got an idea that ripping out classes that could lead to a NoClassDefFoundError for existing users did not fit the definition of "binary compability" f

Re: Resurrecting log4j 1.x

Vladimir, The PMC is totally focused on resolving issues for log4j 2 at the moment. We are still getting tons of emails you can’t see. So if it seems like we are being unhelpful it is entirely because we are focused on that. We’ve stated several times that we don’t think resurrecting Log4j 1.x

Re: Resurrecting log4j 1.x

Ron>wouldn't a more efficient approach be to offer support to Ron>Logging Services Ron, I did try my best to offer my help with updating log4j 1.x. Unfortunately, I failed and none of Logging Services PMC accepted it. Here are the facts: https://lists.apache.org/thread/6lhkyytvpg4md757tfydb1k0mmp5

Re: Forwarding email per Matt Sicker suggestion

Thanks Dick, I am totally unfamiliar with this. Is there somewhere to read about what this is all about? Ralph > On Dec 20, 2021, at 7:18 AM, Dick Brooks > wrote: > > Hello, > > This sort of suggestion would be better sent to our development mailing list > (dev@logging.apache.org

Forwarding email per Matt Sicker suggestion

Hello, This sort of suggestion would be better sent to our development mailing list (dev@logging.apache.org ). I'll note that we use Apache Maven for our build system, and a quick search shows that might be a

Re: Building log4j from source on mac? (toolchain.xml madness!)

Thank you, that was very helpful. For completeness, here is the script that seems to work for me; at least, maven runs to completion. (Might want to remove the jdk 7 section from toolchains-sample-mac.xml in git...?) http://kegel.com/install-log4j2-mac.sh.txt - Dan On Sun, Dec 19, 2021 at 10:19

Re: Resurrecting log4j 1.x

Vladimir, wouldn't a more efficient approach be to offer support to Logging Services then have them make a release to address the recent CVE while still maintaining 1.2.17 compatibility? I don't get the sense folks are against fixing things. Re-starting the entire EOL'ed Log4j1 engine with a ne

Re: Resurrecting log4j 1.x

I don't see the need for the incubator or a new PMC, this is a recipe for confusion for users and contributors: Log4j 1 is a component of the Apache Logging Services project and should remain for Apache to provide the best and consistent *story* for Java logging, at Apache at least. Things are bad

Re: Resurrecting log4j 1.x

"need to move log4j 1.x forward" If this means more than only fixing CVEs it will create a giant hairball of confusion for users between 1.x and 2.x. Gary On Mon, Dec 20, 2021, 09:06 Vladimir Sitnikov wrote: > Ron, > > There's a need to move log4j 1.x forward, and Ralph Goers suggested > that

Re: CVE-2021-45105 and using ctx for router appender

Thank you Ralph! Yes we never drive ${cx:Key} from any input. It's either hardcoded or comes from controlled configuration. On Mon, Dec 20, 2021 at 9:10 AM Leon Finker wrote: > > Hi, > > Could someone please confirm if using ctx in the Routing appender is > not affected by the latest CVE-2021-451

Re: Zero-copy rolling files

Junctions are nice, but I think they are limited to pointing to directories on local file systems. Symlinks can point to remote files and directories on local or remote file systems (including using UNC paths). I didn’t bring up the windows permissions issue with symlinks because I think it is

Re: Resurrecting log4j 1.x

Yes, that is certainly a possibility. For that I don’t think a trip through the incubator would be necessary. But it would also be difficult to make the folks working on log4j 1.x committers of the Logging Services project since gaining commit rights to an ASF project usually requires more tha

Re: Resurrecting log4j 1.x

Dear Ralph, > The reason I brought this up is that it seems there are two groups here. One > that wants to get a release > out and then put Log4j 1 back in the coffin and another that wants to > resurrect it. Do you think there may be a middle ground here? In other words, users who think that

Re: Resurrecting log4j 1.x

The key question is who will be the sponsor: Logging or Incubator. >However, before you even start you need to know >if you have enough people who want to participate tin the project I'm sure there are 3-5 persons that would be willing to cooperate. Vladimir

Re: CVE-2021-45105 and using ctx for router appender

Using ${cx:Key} should not be used in releases below 2.16.0 in a routing key - or anything else that operates during log event processing - IF the key contains data that originates externally. So if your key contains data from an HTTP header and you copy that data into a ThreadContext variabl

CVE-2021-45105 and using ctx for router appender

Hi, Could someone please confirm if using ctx in the Routing appender is not affected by the latest CVE-2021-45105? Example, I wouldn't think so. Just want to double check. Thank you very much!

Re: Resurrecting log4j 1.x

I am sure any number of PMC members would be happy to act as sponsors & mentors. However, before you even start you need to know if you have enough people who want to participate tin the project. The application form needs to include the list of names of people who will become the initial memb

Re: [logging-log4j2] branch java6 created (now a0b0e11)

OK. I originally tried log4j-2.3 as the branch name but that matched an existing tag. log4j-2.3.x should work though Ralph > On Dec 20, 2021, at 6:37 AM, Gary Gregory wrote: > > We need a better branch name IMO... one like the 2.12.x name, 2.12 -> > 2.12.x? java6 -> 2.3.x? > > Gary > > On Mo

Resurrecting log4j 1.x

Ron, There's a need to move log4j 1.x forward, and Ralph Goers suggested that the way to go is to re-incubate it, see [1]. Could you sponsor the project or do you want Incubator to do that? (see [2]) [1]: https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5 [2]: https://lists.apache.

Re: [logging-log4j2] branch java6 created (now a0b0e11)

We need a better branch name IMO... one like the 2.12.x name, 2.12 -> 2.12.x? java6 -> 2.3.x? Gary On Mon, Dec 20, 2021, 00:45 wrote: > This is an automated email from the ASF dual-hosted git repository. > > rgoers pushed a change to branch java6 > in repository https://gitbox.apache.org/repos/

Re: [VOTE] Release log4net 2.0.14

* old-log4net.snk.gpg has been the old key to sign binaries. * @Matt, where is the root logging KEYS file located? The changes in the release look good to me. +1 On Mon, 20 Dec 2021 at 07:34, Davyd McColl wrote: > Thanks Matt > > Since you've given a +1, I'll write up some sticky notes to addre