Re: Regarding the resolution for the latest vulnerability

2021-12-12 Thread Ralph Goers
JNDI was only part of the issue but we did indeed seek to sanitize JNDI as much as we could in 2.15.0. However, we felt it best to disable it by default in 2.16.0 so that it would be more difficult to accidentally use. We will continue to look to improve that sanitization logic so that users w

Re: Regarding the resolution for the latest vulnerability

2021-12-12 Thread Remko Popma
Hi Daniel, The plan is to disable lookups in log messages completely in the next Log4j release. If you can tell us your concrete use case we may be able to advise on how to implement it safely. Lookups in configuration will continue to work (but JNDI will require an extra setting to be enabled).

Regarding the resolution for the latest vulnerability

2021-12-12 Thread Dash a
Hello, Sorry to strom in for a disscusion that probably happened internally but correct me if I am wrong the solution offered doesn't seems to fix the original issue which appear to be due to lack of sanitization but rather disable it by default This seems a bit lacking if it is the case as if so

[VOTE] Release Log4j 2.16.0-rc1

2021-12-12 Thread Matt Sicker
This is a vote to release Log4j 2.16.0, the next version of the Log4j 2 project. 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 72 hours (or more if required). All votes are welco

Re: [VOTE] Release Log4j 2.15.1-rc1

2021-12-12 Thread Ralph Goers
Done, except I made it an info message.I can change it to info if you really think it is appropriate. Ralph > On Dec 12, 2021, at 8:48 PM, Matt Sicker wrote: > > I’m canceling this vote and will start a new one for the updates in progress. > >> On Dec 12, 2021, at 21:41, Remko Popma wrote:

Re: [VOTE] Release Log4j 2.15.1-rc1

2021-12-12 Thread Matt Sicker
I’m canceling this vote and will start a new one for the updates in progress. > On Dec 12, 2021, at 21:41, Remko Popma wrote: > > Okay. Would it be a good idea to retain support for the %m{nolookups} > configuration format? > (Silently accept and ignore it.) Yes, I think it would be a good ide

Re: [VOTE] Release Log4j 2.15.1-rc1

2021-12-12 Thread Remko Popma
Okay. Would it be a good idea to retain support for the %m{nolookups} configuration format? (Silently accept and ignore it.) When the configuration contains %m{lookups}, it may be good to print a WARN message to the status logger that this setting will be ignored. > On Dec 13, 2021, at 12:2

Re: [VOTE] Release Log4j 2.15.1-rc1

2021-12-12 Thread Ralph Goers
I have just put up a PR. Please review it. Either Matt or I can cut a 2.16.0. I don’t see the point of 2.15.1 if we are going to do this. Ralph > On Dec 12, 2021, at 7:49 PM, Gary Gregory wrote: > > I like RERO but 3 releases in a week is a lot even for me :-) > > Gary > > On Sun, Dec 12, 20

Re: [VOTE] Release Log4j 2.15.1-rc1

2021-12-12 Thread Gary Gregory
I like RERO but 3 releases in a week is a lot even for me :-) Gary On Sun, Dec 12, 2021 at 9:41 PM Remko Popma wrote: > It seems that Ralph has already started to work on a PR to remove message > lookups altogether from 2.x. > > I have come around to Volkan’s point that we don’t want to ask use

Re: [VOTE] Release Log4j 2.15.1-rc1

2021-12-12 Thread Remko Popma
It seems that Ralph has already started to work on a PR to remove message lookups altogether from 2.x. I have come around to Volkan’s point that we don’t want to ask users to upgrade Log4j every week. So it maybe better to cancel the 2.15.1 release and have a dedicated security release 2.16.

Re: [VOTE] Release Log4j 2.15.1-rc1

2021-12-12 Thread Gary Gregory
Should we proceed with 2.15.1 or cancel it and go to 2.16.0 straight away? Gary On Sun, Dec 12, 2021, 20:40 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

Re: [VOTE] Release Log4j 2.15.1-rc1

2021-12-12 Thread Remko Popma
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 (removing Message Lookups) in such a 2.16.0 release and not add other features. This will reduce the testi

Re: [logging-log4j2] branch rel created (now 4456909)

2021-12-12 Thread Ralph Goers
Sorry. I missed that a branch named “rel” had been created. I have no idea why that would be. Ralph > On Dec 12, 2021, at 4:21 PM, Gary Gregory wrote: > > Tags that start with rel/ are immutable for Apache repos. But this is a > branch I thought. > > Gary > > On Sun, Dec 12, 2021, 18:01 Ralp

Re: [logging-log4j2] branch rel created (now 4456909)

2021-12-12 Thread Gary Gregory
Tags that start with rel/ are immutable for Apache repos. But this is a branch I thought. Gary On Sun, Dec 12, 2021, 18:01 Ralph Goers wrote: > The tags that start with rel/ are that way because I seem to recall that > there were special rules implemented by infra to prevent that tag from > bei

Re: [VOTE] Release Log4j 2.15.1-rc1

2021-12-12 Thread Ralph Goers
Volkan, While ASF rules say a -1 vote is not a veto for all practical purposes the release manager is going to consider it a blocker. A release that removes JNDI will prevent people from inadvertently using the JNDI Lookup, JMS, or JndiContextSelector without understanding the security risk us

Re: [logging-log4j2] branch rel created (now 4456909)

2021-12-12 Thread Ralph Goers
The tags that start with rel/ are that way because I seem to recall that there were special rules implemented by infra to prevent that tag from being deleted. Of course, now I can’t find the documentation on it. Ralph > On Dec 12, 2021, at 11:51 AM, Gary Gregory wrote: > > If this is supposed

Re: [VOTE] Release Log4j 2.15.1-rc1

2021-12-12 Thread Volkan Yazıcı
You don't need my vote. As far as I count, you already have more than 3. I can imagine Ralph and the rest have worked sleeplessly for days. Hence if they think disabling JNDI buys us a benefit, so be it. If not millions, tens of thousands of people tried to upgrade Log4j to 2.15.0 recently. A rel

Re: [VOTE] Release Log4j 2.15.1-rc1

2021-12-12 Thread Remko Popma
On Mon, Dec 13, 2021 at 5:47 AM Remko Popma wrote: > First, is this really a blocker for 2.15.1? > I think it is prudent to do urgent releases soon. > This JNDI change (LOG4J2-3208 > ) feels urgent enough > to warrant another shortened vote windo

Re: [VOTE] Release Log4j 2.15.1-rc1

2021-12-12 Thread Remko Popma
First, is this really a blocker for 2.15.1? I think it is prudent to do urgent releases soon. This JNDI change (LOG4J2-3208 ) feels urgent enough to warrant another shortened vote window. A larger change like removing message lookups should not be

Re: SetUtils

2021-12-12 Thread Volkan Yazıcı
It is on `master`. On Thu, Dec 9, 2021 at 5:02 PM Volkan Yazıcı wrote: > SetUtils is only used by log4j-web, yet it is in log4j-core. I want to > mark it as deprecated in release-2.x and remove it in master. Objections? >

Re: [VOTE] Release Log4j 2.15.1-rc1

2021-12-12 Thread Remko Popma
Shall we discuss this first please? On Mon, Dec 13, 2021 at 5:10 AM Matt Sicker wrote: > If you can handle that change, I can roll a new release candidate. > > Matt Sicker > > > On Dec 12, 2021, at 14:07, Volkan Yazıcı wrote: > > > > I know. I want them to be removed, not disabled. > > > >> On

Re: [VOTE] Release Log4j 2.15.1-rc1

2021-12-12 Thread Matt Sicker
If you can handle that change, I can roll a new release candidate. Matt Sicker > On Dec 12, 2021, at 14:07, Volkan Yazıcı wrote: > > I know. I want them to be removed, not disabled. > >> On Sun, Dec 12, 2021 at 9:01 PM Matt Sicker wrote: >> >> Those were already disabled in 2.15.0. >> >> M

Re: [VOTE] Release Log4j 2.15.1-rc1

2021-12-12 Thread Volkan Yazıcı
I know. I want them to be removed, not disabled. On Sun, Dec 12, 2021 at 9:01 PM Matt Sicker wrote: > Those were already disabled in 2.15.0. > > Matt Sicker > > > On Dec 12, 2021, at 13:41, Volkan Yazıcı wrote: > > > > I very well recognize your heroic effort on tackling this issue and I am >

Re: [VOTE] Release Log4j 2.15.1-rc1

2021-12-12 Thread Matt Sicker
Those were already disabled in 2.15.0. Matt Sicker > On Dec 12, 2021, at 13:41, Volkan Yazıcı wrote: > > I very well recognize your heroic effort on tackling this issue and I am > very thankful for that. > I vote -1, because I want message (not configuration!) lookups to be > removed. > > Mes

Re: [VOTE] Release Log4j 2.15.1-rc1

2021-12-12 Thread Volkan Yazıcı
I very well recognize your heroic effort on tackling this issue and I am very thankful for that. I vote -1, because I want message (not configuration!) lookups to be removed. Message lookups create a vast attack surface. Anything they offer can simply be implemented by the user. On Sun, Dec 12, 2

Re: [logging-log4j2] branch rel created (now 4456909)

2021-12-12 Thread Gary Gregory
If this is supposed to be a release branch, why not call it 'release'. Calling it 'rel' seems confusing especially when we have a special immutable 'root' tag already called 'rel' in all Apache repos. The abbreviation for tags is also silly IMO, it just obfuscates what should be obvious. Gary On

Re: [VOTE] Release Log4j 2.15.1-rc1

2021-12-12 Thread Gary Gregory
This is what I see on the console and printing the exception from the debugger: 13:42:06,505 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback-test.xml] at [file:/C:/d3vsrc/git/apache/logging-log4j2-2.x/log4j-core/target/test-classes/logback-test.xml] 13:42:06,763 |

Re: [VOTE] Release Log4j 2.15.1-rc1

2021-12-12 Thread Ralph Goers
I’ve verified the 512 SHAs are ok and run the build ok. After getting Matt to update the KEYS file his signature now verifies properly. +1 Ralph > On Dec 12, 2021, at 10:26 AM, Ralph Goers wrote: > > I don’t. But of course I wrote that test. It verifies that if you add dns as > a supported

Re: [VOTE] Release Log4j 2.15.0-rc2

2021-12-12 Thread Carter Kozak
Thanks, Matt. It has been a long day :) On Sun, Dec 12, 2021, at 13:16, Matt Sicker wrote: > This vote thread is already closed. Did you mean to vote on the 2.15.1-rc1 > thread? > > > On Dec 12, 2021, at 11:49, Carter Kozak wrote: > > > > +1 > > > > mvn clean && mvn install > > rat passes > >

Re: [VOTE] Release Log4j 2.15.1-rc1

2021-12-12 Thread Carter Kozak
+1 mvn clean && mvn install rat passes $ mvn -v Apache Maven 3.6.3 Maven home: /usr/share/maven Java version: 1.8.0_282, vendor: Azul Systems, Inc., runtime: /home/ckozak/.tools/jdk/zulu8.52.0.23-ca-jdk8.0.282-linux_x64/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version

Re: [VOTE] Release Log4j 2.15.1-rc1

2021-12-12 Thread Ron Grabowski
+1 for Log4j 2.15.1-rc1, I accidently replied to the wrong thread earlier. mvn clean install -t toolchains-sample-win.xmlmvn apache-rat:checkmvn revapi:check -pl log4j-api Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)Maven home: C:\projects\apache-maven-3.8.4Java version: 1.8.0_1

Re: [VOTE] Release Log4j 2.15.0-rc2

2021-12-12 Thread Matt Sicker
This vote thread is already closed. Did you mean to vote on the 2.15.1-rc1 thread? > On Dec 12, 2021, at 11:49, Carter Kozak wrote: > > +1 > > mvn clean && mvn install > rat passes > $ mvn -v > Apache Maven 3.6.3 > Maven home: /usr/share/maven > Java version: 1.8.0_282, vendor: Azul Systems, I

Re: [VOTE] Release Log4j 2.15.0-rc2

2021-12-12 Thread Carter Kozak
+1 mvn clean && mvn install rat passes $ mvn -v Apache Maven 3.6.3 Maven home: /usr/share/maven Java version: 1.8.0_282, vendor: Azul Systems, Inc., runtime: /home/ckozak/.tools/jdk/zulu8.52.0.23-ca-jdk8.0.282-linux_x64/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version

Re: [VOTE] Release Log4j 2.15.0-rc2

2021-12-12 Thread Ron Grabowski
+1  mvn clean install -t toolchains-sample-win.xml mvn apache-rat:checkmvn revapi:check -pl log4j-api Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)Maven home: C:\projects\apache-maven-3.8.4Java version: 1.8.0_181, vendor: Oracle Corporation, runtime: C:\Program Files\Java\jdk1.8.

Re: [VOTE] Release Log4j 2.15.1-rc1

2021-12-12 Thread Ralph Goers
I don’t. But of course I wrote that test. It verifies that if you add dns as a supported protocol that it can find apache.org. Running it under the debugger it returns a DnsContext for me, which JndiLookup converts to a String which frankly isn’t very useful. com.sun.jndi.dns.DnsContext@4bdcaf3

Re: [VOTE] Release Log4j 2.15.1-rc1

2021-12-12 Thread Gary Gregory
Also, on Windows 10 and Java 8: [ERROR] Failures: [ERROR] JndiRestrictedLookupTest.testDnsLookup:154 No DNS data returned [INFO] [ERROR] Tests run: 2244, Failures: 1, Errors: 0, Skipped: 11 [INFO] Does anyone else get that? Gary On Sun, Dec 12, 2021 at 9:07 AM Gary Gregory wrote: > +1 > >

Re: [VOTE] Release Log4j 2.15.1-rc1

2021-12-12 Thread Gary Gregory
+1 *- I cannot get revapi:check to work on the log4j-api module due to some weird maven dependency issue I cannot resolve, may someone confirm that this check passes?* - Apache RAT check OK - mvn clean package Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) Maven home: /usr/local/C

Re: [VOTE] Release Log4j 2.15.1-rc1

2021-12-12 Thread Remko Popma
+1 build succeeds, all tests 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 encoding: