date:20211212

+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: MS932
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"



On Sun, Dec 12, 2021 at 1:39 PM Gary Gregory  wrote:

> I'll review in the morning (EST).
>
> Gary
>
> On Sat, Dec 11, 2021, 23:02 Matt Sicker  wrote:
>
> > If possible, let’s try to get this vote done over the next 24 hours.
> >
> > Matt Sicker
> >
> > > On Dec 11, 2021, at 21:48, Matt Sicker  wrote:
> > >
> > > This is a vote to release Log4j 2.15.1, 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 welcome and we encourage everyone to test the release, but only
> Logging
> > PMC votes are “officially” counted. As always, at least 3 +1 votes and
> more
> > positive than negative votes are required.
> > >
> > > Changes in this release include:
> > >
> > > Fixed Bugs
> > >
> > > * LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi to be
> > set to true to allow JNDI.
> > >
> > > Tag:
> > > a)  for a new copy do "git clone
> > https://github.com/apache/logging-log4j2.git"; and then "git checkout
> > tags/log4j-2.15.1-rc1”  or just "git clone -b log4j-2.15.1-rc1
> > https://github.com/apache/logging-log4j2.git";
> > > b) for an existing working copy to “git pull” and then “git checkout
> > tags/log4j-2.15.1-rc1”
> > >
> > > Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html.
> > >
> > > Maven Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachelogging-1067/
> > >
> > > Distribution archives:
> > https://dist.apache.org/repos/dist/dev/logging/log4j/
> > >
> > > You may download all the Maven artifacts by executing:
> > > wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
> >
> https://repository.apache.org/content/repositories/orgapachelogging-1067/org/apache/logging/log4j/
> >
>

Re: [VOTE] Release Log4j 2.15.1-rc1

+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/Cellar/maven/3.8.4/libexec
Java version: 1.8.0_292, vendor: AdoptOpenJDK, runtime:
/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"

Darwin *** 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT
2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64

On Sat, Dec 11, 2021 at 10:48 PM Matt Sicker  wrote:

> This is a vote to release Log4j 2.15.1, 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 welcome and we encourage everyone to test the release, but only Logging
> PMC votes are “officially” counted. As always, at least 3 +1 votes and more
> positive than negative votes are required.
>
> Changes in this release include:
>
> Fixed Bugs
>
> * LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi to be
> set to true to allow JNDI.
>
> Tag:
> a)  for a new copy do "git clone
> https://github.com/apache/logging-log4j2.git <
> https://github.com/apache/logging-log4j2.git>" and then "git checkout
> tags/log4j-2.15.1-rc1”  or just "git clone -b log4j-2.15.1-rc1
> https://github.com/apache/logging-log4j2.git <
> https://github.com/apache/logging-log4j2.git>"
> b) for an existing working copy to “git pull” and then “git checkout
> tags/log4j-2.15.1-rc1”
>
> Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html <
> https://logging.staged.apache.org/log4j/2.x/index.html>.
>
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachelogging-1067/
>
> Distribution archives:
> https://dist.apache.org/repos/dist/dev/logging/log4j/ <
> https://dist.apache.org/repos/dist/dev/logging/log4j/>
>
> You may download all the Maven artifacts by executing:
> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
> https://repository.apache.org/content/repositories/orgapachelogging-1067/org/apache/logging/log4j/

Re: [VOTE] Release Log4j 2.15.1-rc1

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
>
> *- 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/Cellar/maven/3.8.4/libexec
> Java version: 1.8.0_292, vendor: AdoptOpenJDK, runtime:
> /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
>
> Darwin *** 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT
> 2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64
>
> On Sat, Dec 11, 2021 at 10:48 PM Matt Sicker  wrote:
>
>> This is a vote to release Log4j 2.15.1, 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 welcome and we encourage everyone to test the release, but only Logging
>> PMC votes are “officially” counted. As always, at least 3 +1 votes and more
>> positive than negative votes are required.
>>
>> Changes in this release include:
>>
>> Fixed Bugs
>>
>> * LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi to be
>> set to true to allow JNDI.
>>
>> Tag:
>> a)  for a new copy do "git clone
>> https://github.com/apache/logging-log4j2.git <
>> https://github.com/apache/logging-log4j2.git>" and then "git checkout
>> tags/log4j-2.15.1-rc1”  or just "git clone -b log4j-2.15.1-rc1
>> https://github.com/apache/logging-log4j2.git <
>> https://github.com/apache/logging-log4j2.git>"
>> b) for an existing working copy to “git pull” and then “git checkout
>> tags/log4j-2.15.1-rc1”
>>
>> Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html <
>> https://logging.staged.apache.org/log4j/2.x/index.html>.
>>
>> Maven Artifacts:
>> https://repository.apache.org/content/repositories/orgapachelogging-1067/
>>
>> Distribution archives:
>> https://dist.apache.org/repos/dist/dev/logging/log4j/ <
>> https://dist.apache.org/repos/dist/dev/logging/log4j/>
>>
>> You may download all the Maven artifacts by executing:
>> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
>> https://repository.apache.org/content/repositories/orgapachelogging-1067/org/apache/logging/log4j/
>
>

Re: [VOTE] Release Log4j 2.15.1-rc1

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@4bdcaf36

Can you run it under the debugger and see what happens inside JndiManager? I 
would expect you are getting an exception.

I should probably consider creating a bogus JNDI protocol and registering it 
for that test instead of doing something real.

Ralph

> On Dec 12, 2021, at 8:51 AM, Gary Gregory  wrote:
> 
> 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
>> 
>> *- 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/Cellar/maven/3.8.4/libexec
>> Java version: 1.8.0_292, vendor: AdoptOpenJDK, runtime:
>> /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
>> Default locale: en_US, platform encoding: UTF-8
>> OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
>> 
>> Darwin *** 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT
>> 2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64
>> 
>> On Sat, Dec 11, 2021 at 10:48 PM Matt Sicker  wrote:
>> 
>>> This is a vote to release Log4j 2.15.1, 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 welcome and we encourage everyone to test the release, but only Logging
>>> PMC votes are “officially” counted. As always, at least 3 +1 votes and more
>>> positive than negative votes are required.
>>> 
>>> Changes in this release include:
>>> 
>>> Fixed Bugs
>>> 
>>> * LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi to be
>>> set to true to allow JNDI.
>>> 
>>> Tag:
>>> a)  for a new copy do "git clone
>>> https://github.com/apache/logging-log4j2.git <
>>> https://github.com/apache/logging-log4j2.git>" and then "git checkout
>>> tags/log4j-2.15.1-rc1”  or just "git clone -b log4j-2.15.1-rc1
>>> https://github.com/apache/logging-log4j2.git <
>>> https://github.com/apache/logging-log4j2.git>"
>>> b) for an existing working copy to “git pull” and then “git checkout
>>> tags/log4j-2.15.1-rc1”
>>> 
>>> Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html <
>>> https://logging.staged.apache.org/log4j/2.x/index.html>.
>>> 
>>> Maven Artifacts:
>>> https://repository.apache.org/content/repositories/orgapachelogging-1067/
>>> 
>>> Distribution archives:
>>> https://dist.apache.org/repos/dist/dev/logging/log4j/ <
>>> https://dist.apache.org/repos/dist/dev/logging/log4j/>
>>> 
>>> You may download all the Maven artifacts by executing:
>>> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
>>> https://repository.apache.org/content/repositories/orgapachelogging-1067/org/apache/logging/log4j/
>> 
>>

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.0_181\jreDefault locale: 
en_US, platform encoding: Cp1252OS name: "windows 10", version: "10.0", arch: 
"amd64", family: "windows"
On Thursday, December 9, 2021, 06:01:28 PM EST, Remko Popma 
 wrote:  
 
   +1

build succeeds and all tests pass on my windows machine.


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: MS932
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Thank you Ralph!


On Fri, Dec 10, 2021 at 7:11 AM Gary Gregory  wrote:

> +1
>
> RAT check OK
> RevApi check OK on log4j-api but gives weird errors on log4j-1.2-api
>
> OK: mvn clean install
>
> Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
> Maven home: /usr/local/Cellar/maven/3.8.4/libexec
> Java version: 1.8.0_292, vendor: AdoptOpenJDK, runtime:
> /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
>
> Darwin *** 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT
> 2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64
>
> Gary
>
>
>
> On Thu, Dec 9, 2021 at 1:43 PM Ralph Goers 
> wrote:
>
> > This is a vote to release Log4j 2.15.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 welcome and we encourage everyone to test the release, but only
> Logging
> > PMC votes are “officially” counted. As always, at least 3 +1 votes and
> more
> > positive than negative votes are required.
> >
> > Changes in this release include:
> >
> > New Features
> >
> >        • LOG4J2-3198: Pattern layout no longer enables lookups within
> > message text by default for cleaner API boundaries and reduced formatting
> > overhead. The old 'log4j2.formatMsgNoLookups' which enabled this behavior
> > has been removed as well as the 'nolookups' message pattern converter
> > option. The old behavior can be enabled on a per-pattern basis using
> > '%m{lookups}'.
> >        • LOG4J2-3194: Allow fractional attributes for size attribute of
> > SizeBsaedTriggeringPolicy. Thanks to markuss.
> >        • LOG4J2-2978: Add support for Jakarta EE 9 (Tomcat 10 / Jetty
> 11)
> > Thanks to Michael Seele.
> >        • LOG4J2-3189: Improve NameAbbreviator worst-case performance.
> >        • LOG4J2-3170: Make CRLF/HTML encoding run in O(n) worst-case
> > time, rather than O(n^2). Thanks to Gareth Smith.
> >        • LOG4J2-3133: Add missing slf4j-api singleton accessors to
> > log4j-slf4j-impl (1.7) StaticMarkerBinder and StaticMDCBinder. This
> doesn't
> > impact behavior or correctness, but avoids throwing and catching
> > NoSuchMethodErrors when slf4j is initialized and avoids linkage linting
> > warnings.
> >        • LOG4J2-2885: Add support for US-style date patterns and
> > micro/nano seconds to FixedDateTime. Thanks to Markus Spann.
> >        • LOG4J2-3116: Add JsonTemplateLayout for Google Cloud Platform
> > structured logging layout.
> >        • LOG4J2-3067: Add CounterResolver to JsonTemplateLayout.
> >        • LOG4J2-3074: Add replacement parameter to
> > ReadOnlyStringMapResolver.
> >        • LOG4J2-3051: Add CaseConverterResolver to JsonTemplateLayout.
> >        • LOG4J2-3064: Add Arbiters and SpringProfile plugin.
> >        • LOG4J2-3056: Refactor MD5 usage for sharing sensitive
> > information. Thanks to Marcono1234.
> >        • LOG4J2-3004: Add plugin support to JsonTemplateLayout.
> >        • LOG4J2-3050: Allow AdditionalFields to be ignored if their
> value
> > is null or a zero-length String.
> >        • LOG4J2-3049: Allow MapMessage and ThreadContext attributes to
> be
> > prefixed.
> >        • LOG4J2=3048: Add improved MapMessge support to GelfLayout.
> >        • LOG4J2-3044: Add RepeatPatternConverter.
> >        • LOG4J2-2940: Context selectors are aware of their dependence
> > upon the callers ClassLoader, allowing basic context selectors to avoid
> the
> > unnecessary overhead of walking the stack to determine the caller's
> > ClassLoader.
> >        • LOG4J2-2940: Add BasicAsyncLoggerContextSelector equivalent to
> > AsyncLoggerContextSelector for applications with a single LoggerContext.
> > This selector avoids classloader lookup overhead incurred by the existing
> > AsyncLoggerContextSelector.
> >        • LOG4J2-3041:

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: "5.13.0-22-generic", arch: "amd64", family: "unix"

-ck

On Sun, Dec 12, 2021, at 12:39, Ron Grabowski wrote:
> +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.0_181\jreDefault locale: 
> en_US, platform encoding: Cp1252OS name: "windows 10", version: "10.0", arch: 
> "amd64", family: "windows"
> On Thursday, December 9, 2021, 06:01:28 PM EST, Remko Popma 
>  wrote:  
>  
>   +1
> 
> build succeeds and all tests pass on my windows machine.
> 
> 
> 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: MS932
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> 
> Thank you Ralph!
> 
> 
> On Fri, Dec 10, 2021 at 7:11 AM Gary Gregory  wrote:
> 
> > +1
> >
> > RAT check OK
> > RevApi check OK on log4j-api but gives weird errors on log4j-1.2-api
> >
> > OK: mvn clean install
> >
> > Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
> > Maven home: /usr/local/Cellar/maven/3.8.4/libexec
> > Java version: 1.8.0_292, vendor: AdoptOpenJDK, runtime:
> > /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
> >
> > Darwin *** 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT
> > 2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64
> >
> > Gary
> >
> >
> >
> > On Thu, Dec 9, 2021 at 1:43 PM Ralph Goers 
> > wrote:
> >
> > > This is a vote to release Log4j 2.15.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 welcome and we encourage everyone to test the release, but only
> > Logging
> > > PMC votes are “officially” counted. As always, at least 3 +1 votes and
> > more
> > > positive than negative votes are required.
> > >
> > > Changes in this release include:
> > >
> > > New Features
> > >
> > >• LOG4J2-3198: Pattern layout no longer enables lookups within
> > > message text by default for cleaner API boundaries and reduced formatting
> > > overhead. The old 'log4j2.formatMsgNoLookups' which enabled this behavior
> > > has been removed as well as the 'nolookups' message pattern converter
> > > option. The old behavior can be enabled on a per-pattern basis using
> > > '%m{lookups}'.
> > >• LOG4J2-3194: Allow fractional attributes for size attribute of
> > > SizeBsaedTriggeringPolicy. Thanks to markuss.
> > >• LOG4J2-2978: Add support for Jakarta EE 9 (Tomcat 10 / Jetty
> > 11)
> > > Thanks to Michael Seele.
> > >• LOG4J2-3189: Improve NameAbbreviator worst-case performance.
> > >• LOG4J2-3170: Make CRLF/HTML encoding run in O(n) worst-case
> > > time, rather than O(n^2). Thanks to Gareth Smith.
> > >• LOG4J2-3133: Add missing slf4j-api singleton accessors to
> > > log4j-slf4j-impl (1.7) StaticMarkerBinder and StaticMDCBinder. This
> > doesn't
> > > impact behavior or correctness, but avoids throwing and catching
> > > NoSuchMethodErrors when slf4j is initialized and avoids linkage linting
> > > warnings.
> > >• LOG4J2-2885: Add support for US-style date patterns and
> > > micro/nano seconds to FixedDateTime. Thanks to Markus Spann.
> > >• LOG4J2-3116: Add JsonTemplateLayout for Google Cloud Platform
> > > structured logging layout.
> > >• LOG4J2-3067: Add CounterResolver to JsonTemplateLayout.
> > >• LOG4J2-3074: Add replacement parameter to
> > > ReadOnlyStringMapResolver.
> > >• LOG4J2-3051: Add CaseConverterResolver to JsonTemplateLayout.
> > >• LOG4J2-3064: Add Arbiters and SpringProfile plugin.
> > >• LOG4J2-3056: Refactor MD5 usage for sharing sensitive
> > > information. Thanks to Marcono1234.
> > >• LOG4J2-3004: Add plugin support to JsonTemplateLayout.
> > >• LOG4J2-3050: Allow AdditionalFields to be ignored if their
> > value
> > > is null or a zero-length String.
> > >• LOG4J2-3049: Allow MapMessage and ThreadContext attributes to
> > be
> > > prefixed.
> > >• LOG4J2=3048: Add

Re: [VOTE] Release Log4j 2.15.0-rc2

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, 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: "5.13.0-22-generic", arch: "amd64", family: "unix"
> 
> -ck
> 
> On Sun, Dec 12, 2021, at 12:39, Ron Grabowski wrote:
>> +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.0_181\jreDefault locale: 
>> en_US, platform encoding: Cp1252OS name: "windows 10", version: "10.0", 
>> arch: "amd64", family: "windows"
>>On Thursday, December 9, 2021, 06:01:28 PM EST, Remko Popma 
>>  wrote:  
>> 
>>  +1
>> 
>> build succeeds and all tests pass on my windows machine.
>> 
>> 
>> 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: MS932
>> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>> 
>> Thank you Ralph!
>> 
>> 
>> On Fri, Dec 10, 2021 at 7:11 AM Gary Gregory  wrote:
>> 
>>> +1
>>> 
>>> RAT check OK
>>> RevApi check OK on log4j-api but gives weird errors on log4j-1.2-api
>>> 
>>> OK: mvn clean install
>>> 
>>> Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
>>> Maven home: /usr/local/Cellar/maven/3.8.4/libexec
>>> Java version: 1.8.0_292, vendor: AdoptOpenJDK, runtime:
>>> /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
>>> Default locale: en_US, platform encoding: UTF-8
>>> OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
>>> 
>>> Darwin *** 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT
>>> 2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64
>>> 
>>> Gary
>>> 
>>> 
>>> 
>>> On Thu, Dec 9, 2021 at 1:43 PM Ralph Goers 
>>> wrote:
>>> 
 This is a vote to release Log4j 2.15.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 welcome and we encourage everyone to test the release, but only
>>> Logging
 PMC votes are “officially” counted. As always, at least 3 +1 votes and
>>> more
 positive than negative votes are required.
 
 Changes in this release include:
 
 New Features
 
   • LOG4J2-3198: Pattern layout no longer enables lookups within
 message text by default for cleaner API boundaries and reduced formatting
 overhead. The old 'log4j2.formatMsgNoLookups' which enabled this behavior
 has been removed as well as the 'nolookups' message pattern converter
 option. The old behavior can be enabled on a per-pattern basis using
 '%m{lookups}'.
   • LOG4J2-3194: Allow fractional attributes for size attribute of
 SizeBsaedTriggeringPolicy. Thanks to markuss.
   • LOG4J2-2978: Add support for Jakarta EE 9 (Tomcat 10 / Jetty
>>> 11)
 Thanks to Michael Seele.
   • LOG4J2-3189: Improve NameAbbreviator worst-case performance.
   • LOG4J2-3170: Make CRLF/HTML encoding run in O(n) worst-case
 time, rather than O(n^2). Thanks to Gareth Smith.
   • LOG4J2-3133: Add missing slf4j-api singleton accessors to
 log4j-slf4j-impl (1.7) StaticMarkerBinder and StaticMDCBinder. This
>>> doesn't
 impact behavior or correctness, but avoids throwing and catching
 NoSuchMethodErrors when slf4j is initialized and avoids linkage linting
 warnings.
   • LOG4J2-2885: Add support for US-style date patterns and
 micro/nano seconds to FixedDateTime. Thanks to Markus Spann.
   • LOG4J2-3116: Add JsonTemplateLayout for Google Cloud Platform
 structured logging layout.
   • LOG4J2-3067: Add CounterResolver to JsonTemplateLayout.
   • LOG4J2-3074: Add replacement parameter to
 ReadOnlyStringMapResolver.
   • LOG4J2-3051: Add CaseConverterResolver to JsonTemplateLayout.
   • LOG4J2-3064: Add Arbiters and SpringProfile plugin.
   • LOG4J2-3056: Refactor MD5 usage for sharing sensitive
 information. Thanks to Marcono1234.
   • LOG4J2-3004: Add plugin support to JsonTemplateLayout.
   • LOG4J2-3050: Allow AdditionalFields to be ignored if their
>>> value
 is null or a zero-le

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_181, vendor: Oracle 
Corporation, runtime: C:\Program Files\Java\jdk1.8.0_181\jreDefault locale: 
en_US, platform encoding: Cp1252OS name: "windows 10", version: "10.0", arch: 
"amd64", family: "windows"

On Sunday, December 12, 2021, 09:07:52 AM EST, Gary Gregory 
 wrote:  
 
 +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/Cellar/maven/3.8.4/libexec
Java version: 1.8.0_292, vendor: AdoptOpenJDK, runtime:
/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"

Darwin *** 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT
2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64

On Sat, Dec 11, 2021 at 10:48 PM Matt Sicker  wrote:

> This is a vote to release Log4j 2.15.1, 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 welcome and we encourage everyone to test the release, but only Logging
> PMC votes are “officially” counted. As always, at least 3 +1 votes and more
> positive than negative votes are required.
>
> Changes in this release include:
>
> Fixed Bugs
>
> * LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi to be
> set to true to allow JNDI.
>
> Tag:
> a)  for a new copy do "git clone
> https://github.com/apache/logging-log4j2.git <
> https://github.com/apache/logging-log4j2.git>" and then "git checkout
> tags/log4j-2.15.1-rc1”  or just "git clone -b log4j-2.15.1-rc1
> https://github.com/apache/logging-log4j2.git <
> https://github.com/apache/logging-log4j2.git>"
> b) for an existing working copy to “git pull” and then “git checkout
> tags/log4j-2.15.1-rc1”
>
> Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html <
> https://logging.staged.apache.org/log4j/2.x/index.html>.
>
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachelogging-1067/
>
> Distribution archives:
> https://dist.apache.org/repos/dist/dev/logging/log4j/ <
> https://dist.apache.org/repos/dist/dev/logging/log4j/>
>
> You may download all the Maven artifacts by executing:
> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
> https://repository.apache.org/content/repositories/orgapachelogging-1067/org/apache/logging/log4j/

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: "5.13.0-22-generic", arch: "amd64", family: "unix"

On Sat, Dec 11, 2021, at 22:48, Matt Sicker wrote:
> This is a vote to release Log4j 2.15.1, 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 
> welcome and we encourage everyone to test the release, but only Logging PMC 
> votes are “officially” counted. As always, at least 3 +1 votes and more 
> positive than negative votes are required.
> 
> Changes in this release include:
> 
> Fixed Bugs
> 
> * LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi to be set 
> to true to allow JNDI.
> 
> Tag: 
> a)  for a new copy do "git clone https://github.com/apache/logging-log4j2.git 
> " and then "git checkout 
> tags/log4j-2.15.1-rc1”  or just "git clone -b log4j-2.15.1-rc1 
> https://github.com/apache/logging-log4j2.git 
> "
> b) for an existing working copy to “git pull” and then “git checkout 
> tags/log4j-2.15.1-rc1”
> 
> Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html 
> .
> 
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachelogging-1067/
> 
> Distribution archives: https://dist.apache.org/repos/dist/dev/logging/log4j/ 
>  
> 
> You may download all the Maven artifacts by executing:
> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate 
> https://repository.apache.org/content/repositories/orgapachelogging-1067/org/apache/logging/log4j/

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
> > $ 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: "5.13.0-22-generic", arch: "amd64", family: 
> > "unix"
> > 
> > -ck
> > 
> > On Sun, Dec 12, 2021, at 12:39, Ron Grabowski wrote:
> >> +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.0_181\jreDefault 
> >> locale: en_US, platform encoding: Cp1252OS name: "windows 10", version: 
> >> "10.0", arch: "amd64", family: "windows"
> >>On Thursday, December 9, 2021, 06:01:28 PM EST, Remko Popma 
> >>  wrote:  
> >> 
> >>  +1
> >> 
> >> build succeeds and all tests pass on my windows machine.
> >> 
> >> 
> >> 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: MS932
> >> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> >> 
> >> Thank you Ralph!
> >> 
> >> 
> >> On Fri, Dec 10, 2021 at 7:11 AM Gary Gregory  
> >> wrote:
> >> 
> >>> +1
> >>> 
> >>> RAT check OK
> >>> RevApi check OK on log4j-api but gives weird errors on log4j-1.2-api
> >>> 
> >>> OK: mvn clean install
> >>> 
> >>> Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
> >>> Maven home: /usr/local/Cellar/maven/3.8.4/libexec
> >>> Java version: 1.8.0_292, vendor: AdoptOpenJDK, runtime:
> >>> /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
> >>> Default locale: en_US, platform encoding: UTF-8
> >>> OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
> >>> 
> >>> Darwin *** 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT
> >>> 2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64
> >>> 
> >>> Gary
> >>> 
> >>> 
> >>> 
> >>> On Thu, Dec 9, 2021 at 1:43 PM Ralph Goers 
> >>> wrote:
> >>> 
>  This is a vote to release Log4j 2.15.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 welcome and we encourage everyone to test the release, but only
> >>> Logging
>  PMC votes are “officially” counted. As always, at least 3 +1 votes and
> >>> more
>  positive than negative votes are required.
>  
>  Changes in this release include:
>  
>  New Features
>  
>    • LOG4J2-3198: Pattern layout no longer enables lookups within
>  message text by default for cleaner API boundaries and reduced formatting
>  overhead. The old 'log4j2.formatMsgNoLookups' which enabled this behavior
>  has been removed as well as the 'nolookups' message pattern converter
>  option. The old behavior can be enabled on a per-pattern basis using
>  '%m{lookups}'.
>    • LOG4J2-3194: Allow fractional attributes for size attribute of
>  SizeBsaedTriggeringPolicy. Thanks to markuss.
>    • LOG4J2-2978: Add support for Jakarta EE 9 (Tomcat 10 / Jetty
> >>> 11)
>  Thanks to Michael Seele.
>    • LOG4J2-3189: Improve NameAbbreviator worst-case performance.
>    • LOG4J2-3170: Make CRLF/HTML encoding run in O(n) worst-case
>  time, rather than O(n^2). Thanks to Gareth Smith.
>    • LOG4J2-3133: Add missing slf4j-api singleton accessors to
>  log4j-slf4j-impl (1.7) StaticMarkerBinder and StaticMDCBinder. This
> >>> doesn't
>  impact behavior or correctness, but avoids throwing and catching
>  NoSuchMethodErrors when slf4j is initialized and avoids linkage linting
>  warnings.
>    • LOG4J2-2885: Add support for US-style date patterns and
>  micro/nano seconds to FixedDateTime. Thanks to Markus Spann.
>    • LOG4J2-3116: Add JsonTemplateLayout for Google Cloud Platform
>  structured logging layout.
>    • LOG4J2-3067: Add CounterResolver to JsonTemplateLayout.
>    • LOG4J2-3074: Add replacement parameter to
>  ReadOnlyStringMapResolver.
>    • LOG4J2-3051: Add CaseConverterResolver to JsonTemplateLayout.
>

Re: [VOTE] Release Log4j 2.15.1-rc1

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 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@4bdcaf36
> 
> Can you run it under the debugger and see what happens inside JndiManager? I 
> would expect you are getting an exception.
> 
> I should probably consider creating a bogus JNDI protocol and registering it 
> for that test instead of doing something real.
> 
> Ralph
> 
>> On Dec 12, 2021, at 8:51 AM, Gary Gregory  wrote:
>> 
>> 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
>>> 
>>> *- 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/Cellar/maven/3.8.4/libexec
>>> Java version: 1.8.0_292, vendor: AdoptOpenJDK, runtime:
>>> /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
>>> Default locale: en_US, platform encoding: UTF-8
>>> OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
>>> 
>>> Darwin *** 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT
>>> 2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64
>>> 
>>> On Sat, Dec 11, 2021 at 10:48 PM Matt Sicker  wrote:
>>> 
 This is a vote to release Log4j 2.15.1, 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 welcome and we encourage everyone to test the release, but only Logging
 PMC votes are “officially” counted. As always, at least 3 +1 votes and more
 positive than negative votes are required.
 
 Changes in this release include:
 
 Fixed Bugs
 
 * LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi to be
 set to true to allow JNDI.
 
 Tag:
 a)  for a new copy do "git clone
 https://github.com/apache/logging-log4j2.git <
 https://github.com/apache/logging-log4j2.git>" and then "git checkout
 tags/log4j-2.15.1-rc1”  or just "git clone -b log4j-2.15.1-rc1
 https://github.com/apache/logging-log4j2.git <
 https://github.com/apache/logging-log4j2.git>"
 b) for an existing working copy to “git pull” and then “git checkout
 tags/log4j-2.15.1-rc1”
 
 Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html <
 https://logging.staged.apache.org/log4j/2.x/index.html>.
 
 Maven Artifacts:
 https://repository.apache.org/content/repositories/orgapachelogging-1067/
 
 Distribution archives:
 https://dist.apache.org/repos/dist/dev/logging/log4j/ <
 https://dist.apache.org/repos/dist/dev/logging/log4j/>
 
 You may download all the Maven artifacts by executing:
 wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
 https://repository.apache.org/content/repositories/orgapachelogging-1067/org/apache/logging/log4j/
>>> 
>>> 
>

Re: [VOTE] Release Log4j 2.15.1-rc1

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 |-INFO in
ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute
not set
13:42:06,773 |-INFO in ch.qos.logback.core.joran.action.AppenderAction -
About to instantiate appender of type [ch.qos.logback.core.FileAppender]
13:42:06,801 |-INFO in ch.qos.logback.core.joran.action.AppenderAction -
Naming appender as [TestLogfile]
13:42:06,829 |-INFO in
ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default
type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder]
property
13:42:06,833 |-WARN in
ch.qos.logback.classic.encoder.PatternLayoutEncoder@61df66b6 - As of
version 1.2.0 "immediateFlush" property should be set within the enclosing
Appender.
13:42:06,833 |-WARN in
ch.qos.logback.classic.encoder.PatternLayoutEncoder@61df66b6 - Please move
"immediateFlush" property into the enclosing appender.
13:42:06,978 |-WARN in
ch.qos.logback.classic.encoder.PatternLayoutEncoder@61df66b6 - Setting the
"immediateFlush" property of the enclosing appender to false
13:42:06,978 |-INFO in ch.qos.logback.core.FileAppender[TestLogfile] - File
property is set to [target/testlogback.log]
13:42:06,985 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction
- Setting level of ROOT logger to DEBUG
13:42:06,985 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction -
Attaching appender named [TestLogfile] to Logger[ROOT]
13:42:06,987 |-INFO in
ch.qos.logback.classic.joran.action.ConfigurationAction - End of
configuration.
13:42:06,989 |-INFO in
ch.qos.logback.classic.joran.JoranConfigurator@50eac852 - Registering
current configuration as safe fallback point

*javax.naming.NameNotFoundException: DNS name not found [response code 3];
remaining name 'apache.org '*
at com.sun.jndi.dns.DnsClient.checkResponseCode(DnsClient.java:660)
at com.sun.jndi.dns.DnsClient.isMatchResponse(DnsClient.java:578)
at com.sun.jndi.dns.DnsClient.doUdpQuery(DnsClient.java:426)
at com.sun.jndi.dns.DnsClient.query(DnsClient.java:211)
at com.sun.jndi.dns.Resolver.query(Resolver.java:81)
at com.sun.jndi.dns.DnsContext.c_lookup(DnsContext.java:290)
at
com.sun.jndi.toolkit.ctx.ComponentContext.p_lookup(ComponentContext.java:542)
at
com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:177)
at
com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.java:205)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at
org.apache.logging.log4j.core.net.JndiManager.lookup(JndiManager.java:273)
at
org.apache.logging.log4j.core.lookup.JndiLookup.lookup(JndiLookup.java:56)
at
org.apache.logging.log4j.core.lookup.AbstractLookup.lookup(AbstractLookup.java:33)
at
org.apache.logging.log4j.core.lookup.JndiRestrictedLookupTest.testDnsLookup(JndiRestrictedLookupTest.java:152)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.zapodot.junit.ldap.internal.EmbeddedLdapRuleImpl$1.evaluate(EmbeddedLdapRuleImpl.java:154)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at
org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:43)
at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(For

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

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 Sun, Dec 12, 2021 at 12:51 PM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> ckozak pushed a change to branch rel
> in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git.
>
>
>   at 4456909  LOG4J2-3208 - Disable JNDI by default
>
> No new revisions were added by this update.
>

Re: [VOTE] Release Log4j 2.15.1-rc1

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, 2021 at 4:48 AM Matt Sicker  wrote:

> This is a vote to release Log4j 2.15.1, 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 welcome and we encourage everyone to test the release, but only Logging
> PMC votes are “officially” counted. As always, at least 3 +1 votes and more
> positive than negative votes are required.
>
> Changes in this release include:
>
> Fixed Bugs
>
> * LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi to be
> set to true to allow JNDI.
>
> Tag:
> a)  for a new copy do "git clone
> https://github.com/apache/logging-log4j2.git <
> https://github.com/apache/logging-log4j2.git>" and then "git checkout
> tags/log4j-2.15.1-rc1”  or just "git clone -b log4j-2.15.1-rc1
> https://github.com/apache/logging-log4j2.git <
> https://github.com/apache/logging-log4j2.git>"
> b) for an existing working copy to “git pull” and then “git checkout
> tags/log4j-2.15.1-rc1”
>
> Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html <
> https://logging.staged.apache.org/log4j/2.x/index.html>.
>
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachelogging-1067/
>
> Distribution archives:
> https://dist.apache.org/repos/dist/dev/logging/log4j/ <
> https://dist.apache.org/repos/dist/dev/logging/log4j/>
>
> You may download all the Maven artifacts by executing:
> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
> https://repository.apache.org/content/repositories/orgapachelogging-1067/org/apache/logging/log4j/

Re: [VOTE] Release Log4j 2.15.1-rc1

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.
> 
> Message lookups create a vast attack surface. Anything they offer can
> simply be implemented by the user.
> 
>> On Sun, Dec 12, 2021 at 4:48 AM Matt Sicker  wrote:
>> 
>> This is a vote to release Log4j 2.15.1, 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 welcome and we encourage everyone to test the release, but only Logging
>> PMC votes are “officially” counted. As always, at least 3 +1 votes and more
>> positive than negative votes are required.
>> 
>> Changes in this release include:
>> 
>> Fixed Bugs
>> 
>> * LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi to be
>> set to true to allow JNDI.
>> 
>> Tag:
>> a)  for a new copy do "git clone
>> https://github.com/apache/logging-log4j2.git <
>> https://github.com/apache/logging-log4j2.git>" and then "git checkout
>> tags/log4j-2.15.1-rc1”  or just "git clone -b log4j-2.15.1-rc1
>> https://github.com/apache/logging-log4j2.git <
>> https://github.com/apache/logging-log4j2.git>"
>> b) for an existing working copy to “git pull” and then “git checkout
>> tags/log4j-2.15.1-rc1”
>> 
>> Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html <
>> https://logging.staged.apache.org/log4j/2.x/index.html>.
>> 
>> Maven Artifacts:
>> https://repository.apache.org/content/repositories/orgapachelogging-1067/
>> 
>> Distribution archives:
>> https://dist.apache.org/repos/dist/dev/logging/log4j/ <
>> https://dist.apache.org/repos/dist/dev/logging/log4j/>
>> 
>> You may download all the Maven artifacts by executing:
>> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
>> https://repository.apache.org/content/repositories/orgapachelogging-1067/org/apache/logging/log4j/

Re: [VOTE] Release Log4j 2.15.1-rc1

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
> > 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, 2021 at 4:48 AM Matt Sicker  wrote:
> >>
> >> This is a vote to release Log4j 2.15.1, 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 welcome and we encourage everyone to test the release, but only
> Logging
> >> PMC votes are “officially” counted. As always, at least 3 +1 votes and
> more
> >> positive than negative votes are required.
> >>
> >> Changes in this release include:
> >>
> >> Fixed Bugs
> >>
> >> * LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi to be
> >> set to true to allow JNDI.
> >>
> >> Tag:
> >> a)  for a new copy do "git clone
> >> https://github.com/apache/logging-log4j2.git <
> >> https://github.com/apache/logging-log4j2.git>" and then "git checkout
> >> tags/log4j-2.15.1-rc1”  or just "git clone -b log4j-2.15.1-rc1
> >> https://github.com/apache/logging-log4j2.git <
> >> https://github.com/apache/logging-log4j2.git>"
> >> b) for an existing working copy to “git pull” and then “git checkout
> >> tags/log4j-2.15.1-rc1”
> >>
> >> Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html <
> >> https://logging.staged.apache.org/log4j/2.x/index.html>.
> >>
> >> Maven Artifacts:
> >>
> https://repository.apache.org/content/repositories/orgapachelogging-1067/
> >>
> >> Distribution archives:
> >> https://dist.apache.org/repos/dist/dev/logging/log4j/ <
> >> https://dist.apache.org/repos/dist/dev/logging/log4j/>
> >>
> >> You may download all the Maven artifacts by executing:
> >> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
> >>
> https://repository.apache.org/content/repositories/orgapachelogging-1067/org/apache/logging/log4j/
>

Re: [VOTE] Release Log4j 2.15.1-rc1

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.
>> 
>> 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.
>>> 
>>> Message lookups create a vast attack surface. Anything they offer can
>>> simply be implemented by the user.
>>> 
 On Sun, Dec 12, 2021 at 4:48 AM Matt Sicker  wrote:
 
 This is a vote to release Log4j 2.15.1, 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 welcome and we encourage everyone to test the release, but only
>> Logging
 PMC votes are “officially” counted. As always, at least 3 +1 votes and
>> more
 positive than negative votes are required.
 
 Changes in this release include:
 
 Fixed Bugs
 
 * LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi to be
 set to true to allow JNDI.
 
 Tag:
 a)  for a new copy do "git clone
 https://github.com/apache/logging-log4j2.git <
 https://github.com/apache/logging-log4j2.git>" and then "git checkout
 tags/log4j-2.15.1-rc1”  or just "git clone -b log4j-2.15.1-rc1
 https://github.com/apache/logging-log4j2.git <
 https://github.com/apache/logging-log4j2.git>"
 b) for an existing working copy to “git pull” and then “git checkout
 tags/log4j-2.15.1-rc1”
 
 Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html <
 https://logging.staged.apache.org/log4j/2.x/index.html>.
 
 Maven Artifacts:
 
>> https://repository.apache.org/content/repositories/orgapachelogging-1067/
 
 Distribution archives:
 https://dist.apache.org/repos/dist/dev/logging/log4j/ <
 https://dist.apache.org/repos/dist/dev/logging/log4j/>
 
 You may download all the Maven artifacts by executing:
 wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
 
>> https://repository.apache.org/content/repositories/orgapachelogging-1067/org/apache/logging/log4j/
>>

Re: [VOTE] Release Log4j 2.15.1-rc1

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 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
> >>> 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, 2021 at 4:48 AM Matt Sicker  wrote:
> 
>  This is a vote to release Log4j 2.15.1, 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 welcome and we encourage everyone to test the release, but only
> >> Logging
>  PMC votes are “officially” counted. As always, at least 3 +1 votes and
> >> more
>  positive than negative votes are required.
> 
>  Changes in this release include:
> 
>  Fixed Bugs
> 
>  * LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi to
> be
>  set to true to allow JNDI.
> 
>  Tag:
>  a)  for a new copy do "git clone
>  https://github.com/apache/logging-log4j2.git <
>  https://github.com/apache/logging-log4j2.git>" and then "git checkout
>  tags/log4j-2.15.1-rc1”  or just "git clone -b log4j-2.15.1-rc1
>  https://github.com/apache/logging-log4j2.git <
>  https://github.com/apache/logging-log4j2.git>"
>  b) for an existing working copy to “git pull” and then “git checkout
>  tags/log4j-2.15.1-rc1”
> 
>  Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html <
>  https://logging.staged.apache.org/log4j/2.x/index.html>.
> 
>  Maven Artifacts:
> 
> >>
> https://repository.apache.org/content/repositories/orgapachelogging-1067/
> 
>  Distribution archives:
>  https://dist.apache.org/repos/dist/dev/logging/log4j/ <
>  https://dist.apache.org/repos/dist/dev/logging/log4j/>
> 
>  You may download all the Maven artifacts by executing:
>  wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
> 
> >>
> https://repository.apache.org/content/repositories/orgapachelogging-1067/org/apache/logging/log4j/
> >>
>

Re: SetUtils

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

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 rushed out like
this, it needs review time.

Second, do we really want to do this? Are we not overreacting?
Would it not be better to remove lookups in message parameters only?
(In implementation terms, resolve all lookups *before* interpolating the
message parameters?)

Also, let me state the obvious, lookups *in configuration* are tremendously
useful and should not be removed.
This may be obvious to some of us, but I just want to make sure there is no
confusion about that (because I personally was confused about this at some
point). :-)

Finally, if we decide to do this, should a change like this be in a
point/bugfix release (2.15.1) or should it be a separate minor release like
2.16.0?



On Mon, Dec 13, 2021 at 5:10 AM Remko Popma  wrote:

> 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 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
>> >>> 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, 2021 at 4:48 AM Matt Sicker 
>> wrote:
>> 
>>  This is a vote to release Log4j 2.15.1, 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 welcome and we encourage everyone to test the release, but only
>> >> Logging
>>  PMC votes are “officially” counted. As always, at least 3 +1 votes
>> and
>> >> more
>>  positive than negative votes are required.
>> 
>>  Changes in this release include:
>> 
>>  Fixed Bugs
>> 
>>  * LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi to
>> be
>>  set to true to allow JNDI.
>> 
>>  Tag:
>>  a)  for a new copy do "git clone
>>  https://github.com/apache/logging-log4j2.git <
>>  https://github.com/apache/logging-log4j2.git>" and then "git
>> checkout
>>  tags/log4j-2.15.1-rc1”  or just "git clone -b log4j-2.15.1-rc1
>>  https://github.com/apache/logging-log4j2.git <
>>  https://github.com/apache/logging-log4j2.git>"
>>  b) for an existing working copy to “git pull” and then “git checkout
>>  tags/log4j-2.15.1-rc1”
>> 
>>  Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html <
>>  https://logging.staged.apache.org/log4j/2.x/index.html>.
>> 
>>  Maven Artifacts:
>> 
>> >>
>> https://repository.apache.org/content/repositories/orgapachelogging-1067/
>> 
>>  Distribution archives:
>>  https://dist.apache.org/repos/dist/dev/logging/log4j/ <
>>  https://dist.apache.org/repos/dist/dev/logging/log4j/>
>> 
>>  You may download all the Maven artifacts by executing:
>>  wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
>> 
>> >>
>> https://repository.apache.org/content/repositories/orgapachelogging-1067/org/apache/logging/log4j/
>> >>
>>
>

Re: [VOTE] Release Log4j 2.15.1-rc1

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 window.
> A larger change like removing message lookups should not be rushed out
> like this, it needs review time.
>
> Second, do we really want to do this? Are we not overreacting?
> Would it not be better to remove lookups in message parameters only?
> (In implementation terms, resolve all lookups *before* interpolating the
> message parameters?)
>
> Also, let me state the obvious, lookups *in configuration* are
> tremendously useful and should not be removed.
> This may be obvious to some of us, but I just want to make sure there is
> no confusion about that (because I personally was confused about this at
> some point). :-)
>
> Finally, if we decide to do this, should a change like this be in a
> point/bugfix release (2.15.x) or should it be a separate minor release like
> 2.16.0?
>

Personally, my preference would be to go ahead with the 2.15.1 release as
it stands (containing only LOG4J2-3208
).
Further improvements can be done incrementally in future releases.


>
>
> On Mon, Dec 13, 2021 at 5:10 AM Remko Popma  wrote:
>
>> 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 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
>>> >>> 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, 2021 at 4:48 AM Matt Sicker 
>>> wrote:
>>> 
>>>  This is a vote to release Log4j 2.15.1, 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 welcome and we encourage everyone to test the release, but only
>>> >> Logging
>>>  PMC votes are “officially” counted. As always, at least 3 +1 votes
>>> and
>>> >> more
>>>  positive than negative votes are required.
>>> 
>>>  Changes in this release include:
>>> 
>>>  Fixed Bugs
>>> 
>>>  * LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi
>>> to be
>>>  set to true to allow JNDI.
>>> 
>>>  Tag:
>>>  a)  for a new copy do "git clone
>>>  https://github.com/apache/logging-log4j2.git <
>>>  https://github.com/apache/logging-log4j2.git>" and then "git
>>> checkout
>>>  tags/log4j-2.15.1-rc1”  or just "git clone -b log4j-2.15.1-rc1
>>>  https://github.com/apache/logging-log4j2.git <
>>>  https://github.com/apache/logging-log4j2.git>"
>>>  b) for an existing working copy to “git pull” and then “git checkout
>>>  tags/log4j-2.15.1-rc1”
>>> 
>>>  Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html <
>>>  https://logging.staged.apache.org/log4j/2.x/index.html>.
>>> 
>>>  Maven Artifacts:
>>> 
>>> >>
>>> https://repository.apache.org/content/repositories/orgapachelogging-1067/
>>> 
>>>  Distribution archives:
>>>  https://dist.apache.org/repos/dist/dev/logging/log4j/ <
>>>  https://dist.apache.org/repos/dist/dev/logging/log4j/>
>>> 
>>>  You may download all the Maven artifacts by executing:
>>>  wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
>>> 
>>> >>
>>> https://repository.apache.org/content/repositories/orgapachelogging-1067/org/apache/logging/log4j/
>>> >>
>>>
>>

Re: [VOTE] Release Log4j 2.15.1-rc1

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 release where JNDI lookup disabled will only adress
people who still (astonishingly!) want to use "message lookups" – correct
me if I'm wrong. Hence, I think in its current form, 2.15.1 will bring more
confusion than benefit to the general audience. I think the fix to the
vulnerability is to disable message lookups, not patches to the JNDI
lookup. I want to believe that users get this fact right and have already
disabled it. We need to be really careful with our next release. We can't
expect people to upgrade once a week. Putting aside the damage it does to
the reputation of the project.

On Sun, Dec 12, 2021 at 9:47 PM 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 window.
> A larger change like removing message lookups should not be rushed out like
> this, it needs review time.
>
> Second, do we really want to do this? Are we not overreacting?
> Would it not be better to remove lookups in message parameters only?
> (In implementation terms, resolve all lookups *before* interpolating the
> message parameters?)
>
> Also, let me state the obvious, lookups *in configuration* are tremendously
> useful and should not be removed.
> This may be obvious to some of us, but I just want to make sure there is no
> confusion about that (because I personally was confused about this at some
> point). :-)
>
> Finally, if we decide to do this, should a change like this be in a
> point/bugfix release (2.15.1) or should it be a separate minor release like
> 2.16.0?
>
>
>
> On Mon, Dec 13, 2021 at 5:10 AM Remko Popma  wrote:
>
> > 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 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
> >> >>> 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, 2021 at 4:48 AM Matt Sicker 
> >> wrote:
> >> 
> >>  This is a vote to release Log4j 2.15.1, 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 welcome and we encourage everyone to test the release, but only
> >> >> Logging
> >>  PMC votes are “officially” counted. As always, at least 3 +1 votes
> >> and
> >> >> more
> >>  positive than negative votes are required.
> >> 
> >>  Changes in this release include:
> >> 
> >>  Fixed Bugs
> >> 
> >>  * LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi
> to
> >> be
> >>  set to true to allow JNDI.
> >> 
> >>  Tag:
> >>  a)  for a new copy do "git clone
> >>  https://github.com/apache/logging-log4j2.git <
> >>  https://github.com/apache/logging-log4j2.git>" and then "git
> >> checkout
> >>  tags/log4j-2.15.1-rc1”  or just "git clone -b log4j-2.15.1-rc1
> >>  https://github.com/apache/logging-log4j2.git <
> >>  https://github.com/apache/logging-log4j2.git>"
> >>  b) for an existing working copy to “git pull” and then “git
> checkout
> >>  tags/log4j-2.15.1-rc1”
> >> 
> >>  Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html
> <
> >>  https://logging.staged.apache.org/log4j/2.x/index.html>.
> >> 
> >>  Maven Artifacts:
> >> 
> >> >>
> >>
> https://repository.apache.org/content/repositories/orgapachelogging-1067/
> >> 
> >>  Distribution archives:
> >>  https://dist.apache.org/repos/dist/dev/logging/log4j/ <
> >>  https://dist.apache.org/repos/dist/dev/logging/log4j/>
> >> 
> >>  You may download all the Maven artifacts by executing:
> >>  wget -e robots=off --cut-dirs=7 -nH -r -p -np
> --no-

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

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 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 Sun, Dec 12, 2021 at 12:51 PM  wrote:
> 
>> This is an automated email from the ASF dual-hosted git repository.
>> 
>> ckozak pushed a change to branch rel
>> in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git.
>> 
>> 
>>  at 4456909  LOG4J2-3208 - Disable JNDI by default
>> 
>> No new revisions were added by this update.
>>

Re: [VOTE] Release Log4j 2.15.1-rc1

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 using them. Message Lookups are a 
different problem. We are not disabling JNDI 
so people can re-enable message lookups. That would be crazy. We are disabling 
JNDI because, despite all the fixes we 
have made, I still don’t trust it.

We have all agreed Message Lookups need to be killed in master. If we are all 
in agreement to kill them now in 2.x I’m 
fine with that but the two are separate issues. 

If you are OK with the release than your vote should be anything but -1. If you 
really feel it needs a -1 then we need to see 
if we are all ok completely removing the option to re-enable message lookups. I 
would completely understand if that is what 
you want and I would support that so please don’t feel pressured to give in.

Ralph


> On Dec 12, 2021, at 2:08 PM, Volkan Yazıcı  wrote:
> 
> 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 release where JNDI lookup disabled will only adress
> people who still (astonishingly!) want to use "message lookups" – correct
> me if I'm wrong. Hence, I think in its current form, 2.15.1 will bring more
> confusion than benefit to the general audience. I think the fix to the
> vulnerability is to disable message lookups, not patches to the JNDI
> lookup. I want to believe that users get this fact right and have already
> disabled it. We need to be really careful with our next release. We can't
> expect people to upgrade once a week. Putting aside the damage it does to
> the reputation of the project.
> 
> On Sun, Dec 12, 2021 at 9:47 PM 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 window.
>> A larger change like removing message lookups should not be rushed out like
>> this, it needs review time.
>> 
>> Second, do we really want to do this? Are we not overreacting?
>> Would it not be better to remove lookups in message parameters only?
>> (In implementation terms, resolve all lookups *before* interpolating the
>> message parameters?)
>> 
>> Also, let me state the obvious, lookups *in configuration* are tremendously
>> useful and should not be removed.
>> This may be obvious to some of us, but I just want to make sure there is no
>> confusion about that (because I personally was confused about this at some
>> point). :-)
>> 
>> Finally, if we decide to do this, should a change like this be in a
>> point/bugfix release (2.15.1) or should it be a separate minor release like
>> 2.16.0?
>> 
>> 
>> 
>> On Mon, Dec 13, 2021 at 5:10 AM Remko Popma  wrote:
>> 
>>> 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 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
>>> 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, 2021 at 4:48 AM Matt Sicker 
 wrote:
 
 This is a vote to release Log4j 2.15.1, 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 welcome and we encourage everyone to test the release, but only
>> Logging
 PMC votes are “officially” counted. As always, at least 3 +1 votes
 and
>> more
 positive than negative votes are required.
 
 Changes in this release include:
 
 Fixed Bugs
 
 * LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi
>> to
 be
>

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

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
> 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 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 Sun, Dec 12, 2021 at 12:51 PM  wrote:
> >
> >> This is an automated email from the ASF dual-hosted git repository.
> >>
> >> ckozak pushed a change to branch rel
> >> in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git.
> >>
> >>
> >>  at 4456909  LOG4J2-3208 - Disable JNDI by default
> >>
> >> No new revisions were added by this update.
> >>
>
>
>

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

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 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
>> 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 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 Sun, Dec 12, 2021 at 12:51 PM  wrote:
>>> 
 This is an automated email from the ASF dual-hosted git repository.
 
 ckozak pushed a change to branch rel
 in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git.
 
 
 at 4456909  LOG4J2-3208 - Disable JNDI by default
 
 No new revisions were added by this update.
 
>> 
>> 
>>

Re: [VOTE] Release Log4j 2.15.1-rc1

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 testing burden for people looking to upgrade.



On Mon, Dec 13, 2021 at 8:12 Ralph Goers  wrote:

> 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 using them. Message Lookups are a
> different problem. We are not disabling JNDI
> so people can re-enable message lookups. That would be crazy. We are
> disabling JNDI because, despite all the fixes we
> have made, I still don’t trust it.
>
> We have all agreed Message Lookups need to be killed in master. If we are
> all in agreement to kill them now in 2.x I’m
> fine with that but the two are separate issues.
>
> If you are OK with the release than your vote should be anything but -1.
> If you really feel it needs a -1 then we need to see
> if we are all ok completely removing the option to re-enable message
> lookups. I would completely understand if that is what
> you want and I would support that so please don’t feel pressured to give
> in.
>
> Ralph
>
>
> > On Dec 12, 2021, at 2:08 PM, Volkan Yazıcı  wrote:
> >
> > 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 release where JNDI lookup disabled will only adress
> > people who still (astonishingly!) want to use "message lookups" – correct
> > me if I'm wrong. Hence, I think in its current form, 2.15.1 will bring
> more
> > confusion than benefit to the general audience. I think the fix to the
> > vulnerability is to disable message lookups, not patches to the JNDI
> > lookup. I want to believe that users get this fact right and have already
> > disabled it. We need to be really careful with our next release. We can't
> > expect people to upgrade once a week. Putting aside the damage it does to
> > the reputation of the project.
> >
> > On Sun, Dec 12, 2021 at 9:47 PM 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 window.
> >> A larger change like removing message lookups should not be rushed out
> like
> >> this, it needs review time.
> >>
> >> Second, do we really want to do this? Are we not overreacting?
> >> Would it not be better to remove lookups in message parameters only?
> >> (In implementation terms, resolve all lookups *before* interpolating the
> >> message parameters?)
> >>
> >> Also, let me state the obvious, lookups *in configuration* are
> tremendously
> >> useful and should not be removed.
> >> This may be obvious to some of us, but I just want to make sure there
> is no
> >> confusion about that (because I personally was confused about this at
> some
> >> point). :-)
> >>
> >> Finally, if we decide to do this, should a change like this be in a
> >> point/bugfix release (2.15.1) or should it be a separate minor release
> like
> >> 2.16.0?
> >>
> >>
> >>
> >> On Mon, Dec 13, 2021 at 5:10 AM Remko Popma 
> wrote:
> >>
> >>> 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 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
> >>> 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, 2021 at 4:48 AM Matt Sicker 
>  wrote:
> 
>  This is a vote to release Log4j 2.15.1, the next version of the
>  Log4j 2
>  project.
> 
>  Please download, test, and cast your votes on the log4j developers
>  list

Re: [VOTE] Release Log4j 2.15.1-rc1

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 *only* have that security change (removing Message
> Lookups) in such a 2.16.0 release and not add other features.
> This will reduce the testing burden for people looking to upgrade.
>
>
>
> On Mon, Dec 13, 2021 at 8:12 Ralph Goers 
> wrote:
>
> > 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 using them. Message Lookups are a
> > different problem. We are not disabling JNDI
> > so people can re-enable message lookups. That would be crazy. We are
> > disabling JNDI because, despite all the fixes we
> > have made, I still don’t trust it.
> >
> > We have all agreed Message Lookups need to be killed in master. If we are
> > all in agreement to kill them now in 2.x I’m
> > fine with that but the two are separate issues.
> >
> > If you are OK with the release than your vote should be anything but -1.
> > If you really feel it needs a -1 then we need to see
> > if we are all ok completely removing the option to re-enable message
> > lookups. I would completely understand if that is what
> > you want and I would support that so please don’t feel pressured to give
> > in.
> >
> > Ralph
> >
> >
> > > On Dec 12, 2021, at 2:08 PM, Volkan Yazıcı  wrote:
> > >
> > > 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 release where JNDI lookup disabled will only adress
> > > people who still (astonishingly!) want to use "message lookups" –
> correct
> > > me if I'm wrong. Hence, I think in its current form, 2.15.1 will bring
> > more
> > > confusion than benefit to the general audience. I think the fix to the
> > > vulnerability is to disable message lookups, not patches to the JNDI
> > > lookup. I want to believe that users get this fact right and have
> already
> > > disabled it. We need to be really careful with our next release. We
> can't
> > > expect people to upgrade once a week. Putting aside the damage it does
> to
> > > the reputation of the project.
> > >
> > > On Sun, Dec 12, 2021 at 9:47 PM 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 window.
> > >> A larger change like removing message lookups should not be rushed out
> > like
> > >> this, it needs review time.
> > >>
> > >> Second, do we really want to do this? Are we not overreacting?
> > >> Would it not be better to remove lookups in message parameters only?
> > >> (In implementation terms, resolve all lookups *before* interpolating
> the
> > >> message parameters?)
> > >>
> > >> Also, let me state the obvious, lookups *in configuration* are
> > tremendously
> > >> useful and should not be removed.
> > >> This may be obvious to some of us, but I just want to make sure there
> > is no
> > >> confusion about that (because I personally was confused about this at
> > some
> > >> point). :-)
> > >>
> > >> Finally, if we decide to do this, should a change like this be in a
> > >> point/bugfix release (2.15.1) or should it be a separate minor release
> > like
> > >> 2.16.0?
> > >>
> > >>
> > >>
> > >> On Mon, Dec 13, 2021 at 5:10 AM Remko Popma 
> > wrote:
> > >>
> > >>> 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 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
> > >>> very thankful for that.
> > >>> I vote -1, because I want message (not configuration!) lookups to
> > be
> > >>> removed.
> > >>>
> > >>> Message lookups cre

Re: [VOTE] Release Log4j 2.15.1-rc1

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.0 with just the JNDI change and removing message lookups 
altogether. 

Does anyone have a strong desire to release 2.15.1 with just the JNDI change?


> On Dec 13, 2021, at 11:06, Gary Gregory  wrote:
> 
> 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 *only* have that security change (removing Message
>> Lookups) in such a 2.16.0 release and not add other features.
>> This will reduce the testing burden for people looking to upgrade.
>> 
>> 
>> 
>> On Mon, Dec 13, 2021 at 8:12 Ralph Goers 
>> wrote:
>> 
>>> 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 using them. Message Lookups are a
>>> different problem. We are not disabling JNDI
>>> so people can re-enable message lookups. That would be crazy. We are
>>> disabling JNDI because, despite all the fixes we
>>> have made, I still don’t trust it.
>>> 
>>> We have all agreed Message Lookups need to be killed in master. If we are
>>> all in agreement to kill them now in 2.x I’m
>>> fine with that but the two are separate issues.
>>> 
>>> If you are OK with the release than your vote should be anything but -1.
>>> If you really feel it needs a -1 then we need to see
>>> if we are all ok completely removing the option to re-enable message
>>> lookups. I would completely understand if that is what
>>> you want and I would support that so please don’t feel pressured to give
>>> in.
>>> 
>>> Ralph
>>> 
>>> 
 On Dec 12, 2021, at 2:08 PM, Volkan Yazıcı  wrote:
 
 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 release where JNDI lookup disabled will only adress
 people who still (astonishingly!) want to use "message lookups" –
>> correct
 me if I'm wrong. Hence, I think in its current form, 2.15.1 will bring
>>> more
 confusion than benefit to the general audience. I think the fix to the
 vulnerability is to disable message lookups, not patches to the JNDI
 lookup. I want to believe that users get this fact right and have
>> already
 disabled it. We need to be really careful with our next release. We
>> can't
 expect people to upgrade once a week. Putting aside the damage it does
>> to
 the reputation of the project.
 
 On Sun, Dec 12, 2021 at 9:47 PM 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 window.
> A larger change like removing message lookups should not be rushed out
>>> like
> this, it needs review time.
> 
> Second, do we really want to do this? Are we not overreacting?
> Would it not be better to remove lookups in message parameters only?
> (In implementation terms, resolve all lookups *before* interpolating
>> the
> message parameters?)
> 
> Also, let me state the obvious, lookups *in configuration* are
>>> tremendously
> useful and should not be removed.
> This may be obvious to some of us, but I just want to make sure there
>>> is no
> confusion about that (because I personally was confused about this at
>>> some
> point). :-)
> 
> Finally, if we decide to do this, should a change like this be in a
> point/bugfix release (2.15.1) or should it be a separate minor release
>>> like
> 2.16.0?
> 
> 
> 
> On Mon, Dec 13, 2021 at 5:10 AM Remko Popma 
>>> wrote:
> 
>> 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 Sun, Dec 12,

Re: [VOTE] Release Log4j 2.15.1-rc1

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 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.0 with just the JNDI change and removing message
> lookups altogether.
>
> Does anyone have a strong desire to release 2.15.1 with just the JNDI
> change?
>
>
> > On Dec 13, 2021, at 11:06, Gary Gregory  wrote:
> >
> > 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 *only* have that security change (removing
> Message
> >> Lookups) in such a 2.16.0 release and not add other features.
> >> This will reduce the testing burden for people looking to upgrade.
> >>
> >>
> >>
> >> On Mon, Dec 13, 2021 at 8:12 Ralph Goers 
> >> wrote:
> >>
> >>> 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 using them. Message Lookups
> are a
> >>> different problem. We are not disabling JNDI
> >>> so people can re-enable message lookups. That would be crazy. We are
> >>> disabling JNDI because, despite all the fixes we
> >>> have made, I still don’t trust it.
> >>>
> >>> We have all agreed Message Lookups need to be killed in master. If we
> are
> >>> all in agreement to kill them now in 2.x I’m
> >>> fine with that but the two are separate issues.
> >>>
> >>> If you are OK with the release than your vote should be anything but
> -1.
> >>> If you really feel it needs a -1 then we need to see
> >>> if we are all ok completely removing the option to re-enable message
> >>> lookups. I would completely understand if that is what
> >>> you want and I would support that so please don’t feel pressured to
> give
> >>> in.
> >>>
> >>> Ralph
> >>>
> >>>
>  On Dec 12, 2021, at 2:08 PM, Volkan Yazıcı  wrote:
> 
>  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 release where JNDI lookup disabled will only adress
>  people who still (astonishingly!) want to use "message lookups" –
> >> correct
>  me if I'm wrong. Hence, I think in its current form, 2.15.1 will bring
> >>> more
>  confusion than benefit to the general audience. I think the fix to the
>  vulnerability is to disable message lookups, not patches to the JNDI
>  lookup. I want to believe that users get this fact right and have
> >> already
>  disabled it. We need to be really careful with our next release. We
> >> can't
>  expect people to upgrade once a week. Putting aside the damage it does
> >> to
>  the reputation of the project.
> 
>  On Sun, Dec 12, 2021 at 9:47 PM 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 window.
> > A larger change like removing message lookups should not be rushed
> out
> >>> like
> > this, it needs review time.
> >
> > Second, do we really want to do this? Are we not overreacting?
> > Would it not be better to remove lookups in message parameters only?
> > (In implementation terms, resolve all lookups *before* interpolating
> >> the
> > message parameters?)
> >
> > Also, let me state the obvious, lookups *in configuration* are
> >>> tremendously
> > useful and should not be removed.
> > This may be obvious to some of us, but I just want to make sure there
> >>> is no
> > confusion about that (because I personally was confused about this at
> >>> some
> > point). :-)
> >
> > Finally, if we decide to do this, should a change like this be in a
> > point/bugfix release (2.15.1) or should it be a separate minor
> release
> >>> like
> > 2.16.0?
> >
> >
> >
> > On Mon, Dec 13, 2021 at 5:10 AM Remko Popma 
> >>> wrote:
> >
> >> Shall we discuss this first ple

Re: [VOTE] Release Log4j 2.15.1-rc1

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, 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 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.0 with just the JNDI change and removing message
>> lookups altogether.
>> 
>> Does anyone have a strong desire to release 2.15.1 with just the JNDI
>> change?
>> 
>> 
>>> On Dec 13, 2021, at 11:06, Gary Gregory  wrote:
>>> 
>>> 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 *only* have that security change (removing
>> Message
 Lookups) in such a 2.16.0 release and not add other features.
 This will reduce the testing burden for people looking to upgrade.
 
 
 
 On Mon, Dec 13, 2021 at 8:12 Ralph Goers 
 wrote:
 
> 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 using them. Message Lookups
>> are a
> different problem. We are not disabling JNDI
> so people can re-enable message lookups. That would be crazy. We are
> disabling JNDI because, despite all the fixes we
> have made, I still don’t trust it.
> 
> We have all agreed Message Lookups need to be killed in master. If we
>> are
> all in agreement to kill them now in 2.x I’m
> fine with that but the two are separate issues.
> 
> If you are OK with the release than your vote should be anything but
>> -1.
> If you really feel it needs a -1 then we need to see
> if we are all ok completely removing the option to re-enable message
> lookups. I would completely understand if that is what
> you want and I would support that so please don’t feel pressured to
>> give
> in.
> 
> Ralph
> 
> 
>> On Dec 12, 2021, at 2:08 PM, Volkan Yazıcı  wrote:
>> 
>> 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 release where JNDI lookup disabled will only adress
>> people who still (astonishingly!) want to use "message lookups" –
 correct
>> me if I'm wrong. Hence, I think in its current form, 2.15.1 will bring
> more
>> confusion than benefit to the general audience. I think the fix to the
>> vulnerability is to disable message lookups, not patches to the JNDI
>> lookup. I want to believe that users get this fact right and have
 already
>> disabled it. We need to be really careful with our next release. We
 can't
>> expect people to upgrade once a week. Putting aside the damage it does
 to
>> the reputation of the project.
>> 
>> On Sun, Dec 12, 2021 at 9:47 PM 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 window.
>>> A larger change like removing message lookups should not be rushed
>> out
> like
>>> this, it needs review time.
>>> 
>>> Second, do we really want to do this? Are we not overreacting?
>>> Would it not be better to remove lookups in message parameters only?
>>> (In implementation terms, resolve all lookups *before* interpolating
 the
>>> message parameters?)
>>> 
>>> Also, let me state the obvious, lookups *in configuration* are
> tremendously
>>> useful and should not be removed.
>>> This may be obvious to some of us, but I just want to make sure there
> is no
>>> confusion about that (because I personally was confused about this at
> some
>>> point). :-)
>>> 
>>> Finally, if we decide to do this, should a change

Re: [VOTE] Release Log4j 2.15.1-rc1

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:24, Ralph Goers  wrote:
> 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, 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 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.0 with just the JNDI change and removing message
>>> lookups altogether.
>>> Does anyone have a strong desire to release 2.15.1 with just the JNDI
>>> change?
 On Dec 13, 2021, at 11:06, Gary Gregory  wrote:
 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 *only* have that security change (removing
>>> Message
> Lookups) in such a 2.16.0 release and not add other features.
> This will reduce the testing burden for people looking to upgrade.
> On Mon, Dec 13, 2021 at 8:12 Ralph Goers 
> wrote:
>> 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 using them. Message Lookups
>>> are a
>> different problem. We are not disabling JNDI
>> so people can re-enable message lookups. That would be crazy. We are
>> disabling JNDI because, despite all the fixes we
>> have made, I still don’t trust it.
>> We have all agreed Message Lookups need to be killed in master. If we
>>> are
>> all in agreement to kill them now in 2.x I’m
>> fine with that but the two are separate issues.
>> If you are OK with the release than your vote should be anything but
>>> -1.
>> If you really feel it needs a -1 then we need to see
>> if we are all ok completely removing the option to re-enable message
>> lookups. I would completely understand if that is what
>> you want and I would support that so please don’t feel pressured to
>>> give
>> in.
>> Ralph
>>> On Dec 12, 2021, at 2:08 PM, Volkan Yazıcı  wrote:
>>> 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 release where JNDI lookup disabled will only adress
>>> people who still (astonishingly!) want to use "message lookups" –
> correct
>>> me if I'm wrong. Hence, I think in its current form, 2.15.1 will bring
>> more
>>> confusion than benefit to the general audience. I think the fix to the
>>> vulnerability is to disable message lookups, not patches to the JNDI
>>> lookup. I want to believe that users get this fact right and have
> already
>>> disabled it. We need to be really careful with our next release. We
> can't
>>> expect people to upgrade once a week. Putting aside the damage it does
> to
>>> the reputation of the project.
>>> On Sun, Dec 12, 2021 at 9:47 PM 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 window.
 A larger change like removing message lookups should not be rushed
>>> out
>> like
 this, it needs review time.
 Second, do we really want to do this? Are we not overreacting?
 Would it not be better to remove lookups in message parameters only?
 (In implementation terms, resolve all lookups *before* interpolating
> the
 message parameters?)
 Also, let me state the obvious, lookups *in configuration* are
>> tremendously
 useful and should not be removed.
 This

Re: [VOTE] Release Log4j 2.15.1-rc1

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 idea.

Re: [VOTE] Release Log4j 2.15.1-rc1

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:
>> 
>> 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 idea.
> 
>

[VOTE] Release Log4j 2.16.0-rc1

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
welcome and we encourage everyone to test the release, but only Logging PMC
votes are “officially” counted. As always, at least 3 +1 votes and more
positive than negative votes are required.

Changes in this release include:

Fixed Bugs

* LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi to be set to
true to allow JNDI.
* LOG4J2-3211: Completely remove support for Message Lookups.

Tag:
a) for a new copy do "git clone https://github.com/apache/logging-log4j2.git
" and then "git checkout
tags/log4j-2.16.0-rc1” or just "git clone -b log4j-2.16.0-rc1
https://github.com/apache/logging-log4j2.git
"
b) for an existing working copy to “git pull” and then “git checkout
tags/log4j-2.16.0-rc1”

Web Site: https://logging.staged.apache.org/log4j/2.x/index.html
.

Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachelogging-1068

Distribution archives: https://dist.apache.org/repos/dist/dev/logging/log4j/

You may download all the Maven artifacts by executing:
wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
https://repository.apache.org/content/repositories/orgapachelogging-1068/org/apache/logging/log4j/
--
Matt Sicker

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 some software happen to
have a use case for the feature they will be forced to apply each his own
variant solution and otherwise can be accessed by other vulnerabilities.

Hope you could verify regarding those concerns
Daniel

Re: Regarding the resolution for the latest vulnerability

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).

On Mon, Dec 13, 2021 at 16:40 Dash a  wrote:

> 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 some software happen to
> have a use case for the feature they will be forced to apply each his own
> variant solution and otherwise can be accessed by other vulnerabilities.
>
> Hope you could verify regarding those concerns
> Daniel
>

Re: Regarding the resolution for the latest vulnerability