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

+1 Verified signatures, SHA512 files and that the build succeeded on my MacBook Pro. Ralph > On Dec 13, 2021, at 10:38 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

Re: [VOTE] Release Log4j 2.12.2-rc1

+1 Builds fine, sigs good, etc. On Mon, Dec 13, 2021 at 11:58 PM Ralph Goers wrote: > > This is a vote to release Log4j 2.12.2, 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

[VOTE] Release Log4j 2.12.2-rc1

This is a vote to release Log4j 2.12.2, 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.

[VOTE] Release Log4j Kotlin API 1.2.0-rc1

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: LOG4J2-3213 CVE missing CPE information in NVD

I did not fix that. As for how they’re made, I found the CPE database and searched for log4j to find the existing strings. As for editing CVEs, that’s through this site: https://cveprocess.apache.org/ -- Matt Sicker > On Dec 13, 2021, at 16:04, Volkan Yazıcı wrote: > > Matt, I see that it is f

Re: Re: Regarding the resolution for the latest vulnerability

Our latest release, 2.16.0, completely removes the message lookup functionality which makes it impossible to inadvertently re-enable. On Mon, Dec 13, 2021 at 4:58 PM Dash a wrote: > > Hello, > Thanks for the explanation. It is a bit more relaxing. > > As for current concerns - upon a bit of thoug

RE: Re: Regarding the resolution for the latest vulnerability

Hello, Thanks for the explanation. It is a bit more relaxing. As for current concerns - upon a bit of thought i see it as concerning if the current implementation doesn't warn the user when it is enabled. This can present issue in auditing or false negative result in case of supply chain attack/l

[ANNOUNCE] Apache Log4j 2.16.0 Released

The Apache Log4j 2 team is pleased to announce the Log4j 2.16.0 release! Apache Log4j is a well known framework for logging application behavior. Log4j 2 is an upgrade to Log4j that provides significant improvements over its predecessor, Log4j 1.x, and provides many other modern features such as s

Re: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Darn! I have remarked this discrepancy in 2.16.0-rc1 voting! On Mon, Dec 13, 2021 at 8:51 PM Gary Gregory wrote: > Wouldn't this be better: > > diff --git > > a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/Interpolator.java > > b/log4j-core/src/main/java/org/apache/logging/log4j

Re: LOG4J2-3213 CVE missing CPE information in NVD

Matt, I see that it is fixed in https://nvd.nist.gov/vuln/detail/CVE-2021-44228 Did you do it? If so, 1. How did you come up with CPEs? 2. How did you edit the CVE? On Mon, Dec 13, 2021 at 6:50 PM Matt Sicker wrote: > Based on existing CPEs, I think it would look something like: > > cpe:2.3:a:a

Re: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Well, the mitigation of deleting the file is for older releases, not the current ones, right? On Mon, Dec 13, 2021 at 1:53 PM Gary Gregory wrote: > > Never mind, that hard reference is from 2 days ago... BUT... if someone > decides to apply this command to a current version, not so good. > > Gary

Re: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Never mind, that hard reference is from 2 days ago... BUT... if someone decides to apply this command to a current version, not so good. Gary On Mon, Dec 13, 2021 at 2:51 PM Gary Gregory wrote: > Wouldn't this be better: > > diff --git > a/log4j-core/src/main/java/org/apache/logging/log4j/core/

Re: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Wouldn't this be better: diff --git a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/Interpolator.java b/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/Interpolator.java index 75c0a45..9c491ac 100644 --- a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class This can't be right, can it? We have a hard reference to that class in org.apache.logging.log4j.core.lookup.Interpolator Should we really recommend this? Gary

Re: [VOTE] Release Log4j 2.15.1-rc1

I agree too. I was just worried that we wouldn't remove Message Lookups until 3.x. Removing them in the next minor release (2.16.0) is reasonable. On 2021-12-13 10:12, Volkan Yazıcı wrote: I agree with both of your points Remko. On Mon, Dec 13, 2021 at 2:40 AM Remko Popma wrote: I am also

Re: [VOTE] Release Log4j 2.16.0-rc1

I saw the vote has already been closed on log4j-2.16.0-rc1, +1 from me for completeness. No cassandra errors with rat:check this time: mvn clean install -t toolchains-sample-win.xml mvn revapi:check -pl log4j-api mvn apache-rat:check Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)

Re: LOG4J2-3213 CVE missing CPE information in NVD

Based on existing CPEs, I think it would look something like: cpe:2.3:a:apache:log4j:*:*:*:*:*:*:*:* up to version 2.14.1 are affected. On Mon, Dec 13, 2021 at 3:31 AM Volkan Yazıcı wrote: > > Mind somebody helping with LOG4J2-3213 > , please? I

[VOTE][RESULT] Release Log4j 2.16.0-rc1

And my +1. This makes 5 +1 votes, no -1 votes. I’ll continue with the release. -- Matt Sicker > On Dec 13, 2021, at 09:30, Gary Gregory wrote: > > Depending on the RM's availability, I think we can proceed here. > > Gary > > On Mon, Dec 13, 2021 at 10:30 AM Gary Gregory > wrote: > >> Dependi

CVE-2021-4104: Deserialization of untrusted data in JMSAppender in Apache Log4j 1.2

Description: JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests tha

Re: [GitHub] [logging-log4j2] sushain-pandit commented on pull request #608: Restrict LDAP access via JNDI

1.2 has been EOL for years so it has not received any attention, but the JMS Appender is the only one that uses the JNDI API in 1.2, so it should be OK otherwise. Gary On Mon, Dec 13, 2021 at 10:55 AM GitBox wrote: > > sushain-pandit commented on pull request #608: > URL: > https://github.com/a

Re: [VOTE] Release Log4j 2.16.0-rc1

Depending on the RM's availability, I think we can proceed here. Gary On Mon, Dec 13, 2021 at 10:30 AM Gary Gregory wrote: > Depending on the RM's availability > > On Mon, Dec 13, 2021 at 8:04 AM Gary Gregory > wrote: > >> +1 >> >> mvn clean package >> mvn apache-rat:check >> >> Is this comman

Re: [VOTE] Release Log4j 2.16.0-rc1

Depending on the RM's availability On Mon, Dec 13, 2021 at 8:04 AM Gary Gregory wrote: > +1 > > mvn clean package > mvn apache-rat:check > > Is this command 'wrong'? > mvn revapi:check -pl log4j-api > I get errors. > > My Maven toolchain file contains mappings for Java 8, 11, 17. > > Same failur

Re: [VOTE] Release Log4j 2.16.0-rc1

+1 mvn clean package mvn apache-rat:check Is this command 'wrong'? mvn revapi:check -pl log4j-api I get errors. My Maven toolchain file contains mappings for Java 8, 11, 17. Same failure as before on Windows 10 and Java 8 in the restricted JNDI test. Could be something odd with my set up I supp

Re: [VOTE] Release Log4j 2.15.1-rc1

JNDI is commonly used to configure JMS and JDBC. Gary On Mon, Dec 13, 2021 at 4:12 AM Volkan Yazıcı wrote: > Thanks so much for your understanding Ralph, it is very important for me. > > For one, message lookups are nothing but a plethora of vulnerabilities. I > think everybody agrees on this.

Re: [logging-log4j2] branch release-2.x updated: Remove SetUtils from core.

It is only used at configuration start, hence I don't think it is needed. Nevertheless, I have replaced it with Strings.EMPTY_ARRAY. On Mon, Dec 13, 2021 at 12:39 PM Gary Gregory wrote: > +return new String[0]; > > This should be a constant. > > Gary > > On Mon, Dec 13, 2021 at 6:35

Re: [logging-log4j2] branch release-2.x updated: Remove SetUtils from core.

+return new String[0]; This should be a constant. Gary On Mon, Dec 13, 2021 at 6:35 AM wrote: > This is an automated email from the ASF dual-hosted git repository. > > vy pushed a commit to branch release-2.x > in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git >

Re: [VOTE] Release Log4j 2.16.0-rc1

+1 build succeeds and tests all pass Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117; 2019-08-28T00:06:16+09:00) Maven home: C:\apps\apache-maven-3.6.2\bin\.. Java version: 1.8.0_202, vendor: Oracle Corporation, runtime: C:\apps\jdk1.8.0_202\jre Default locale: en_GB, platform encodin

Re: [VOTE] Release Log4j 2.16.0-rc1

+1 `./mvnw verify` on `log4j-2.16.0-rc1` branch passes with the following setup: $ java -version openjdk version "1.8.0_312" OpenJDK Runtime Environment (Zulu 8.58.0.13-CA-linux64) (build 1.8.0_312-b07) OpenJDK 64-Bit Server VM (Zulu 8.58.0.13-CA-linux64) (build 25.312-b07, mixed mode) $ java -v

LOG4J2-3213 CVE missing CPE information in NVD

Mind somebody helping with LOG4J2-3213 , please? I have no idea how this entire CVE process is managed and updated. I would appreciate it if the one who performs the correction can also share how he/she did that. So that next time first-timers like

Re: [VOTE] Release Log4j 2.15.1-rc1

I agree with both of your points Remko. On Mon, Dec 13, 2021 at 2:40 AM Remko Popma wrote: > I am also okay with removing Message Lookups from 2.x. > A release with that change should be called 2.16.0 though, not 2.15.1 or > 2.15.2. > > Also it makes sense to *only* have that security change (re

Re: [VOTE] Release Log4j 2.15.1-rc1

Thanks so much for your understanding Ralph, it is very important for me. For one, message lookups are nothing but a plethora of vulnerabilities. I think everybody agrees on this. We shouldn't try to make it secure, we _must_ ditch it off. Second, I think, again, we shouldn't even be trying to in

Re: [VOTE] Release Log4j 2.16.0-rc1

+1 Verified the signature and the SHA512 hashes. Verified the build worked for me. I did correct some mistakes in the staging site home page news section as it still referenced 2.15.1. Ralph > On Dec 12, 2021, at 11:18 PM, Matt Sicker wrote: > > This is a vote to release Log4j 2.16.0, the n