date:20211213

+1

Verified signatures, SHA512 files and that the build succeeded on my MacBook 
Pro.

Ralph

> On Dec 13, 2021, at 10:38 PM, Matt Sicker  wrote:
> 
> This is a vote to release Log4j Kotlin API version 1.2.0, the next version of 
> the Kotlin facade for Log4j2.
> 
> Please download, test, and cast your votes on the log4j developers list.
> [] +1, release the artifacts
> [] -1, don't release because...
> 
> The vote will remain open for 24 hours (or more if 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 votesand more 
> positive than negative votes are required.
> 
> Changes in this release include:
> 
> * LOG4J2-3218: Update Log4j dependency to 2.16.0.
> 
> This is primarily provided to help upgrade transitive dependencies on 
> log4j-core which was recently updated to fix CVE-2021-44228.
> 
> Tag: 
> a)  for a new copy do "git clone 
> https://github.com/apache/logging-log4j-kotlin.git 
> ” and then "git checkout 
> tags/log4j-api-kotlin-1.2.0-rc1”  or just "git clone -b 
> log4j-api-kotlin-1.2.0-rc1 https://github.com/apache/logging-log4j-kotlin.git 
> "
> b) for an existing working copy to “git pull” and then “git checkout 
> tags/log4j-api-kotlin-1.2.0-rc1”
> 
> Web Site: https://logging.staged.apache.org/log4j/kotlin/index.html
> 
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachelogging-1069/
> 
> Distribution archives: 
> https://dist.apache.org/repos/dist/dev/logging/log4j/kotlin/
> 
> 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-1069/org/apache/logging/log4j/
> 
> --
> Matt Sicker
>

Re: [VOTE] Release Log4j 2.12.2-rc1

+1

Builds fine, sigs good, etc.

On Mon, Dec 13, 2021 at 11:58 PM Ralph Goers  wrote:
>
> This is a vote to release Log4j 2.12.2, a security release for Java 7 users.
>
> Please download, test, and cast your votes on the log4j developers list.
> [] +1, release the artifacts
> [] -1, don't release because...
>
> The vote will remain open for as short amount as time as required to vet the 
> release. 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 version include:
>
> Fixed Bugs
>
> • LOG4J-3220: Disable JNDI by default, remove JNDI Lookup, remove 
> message lookups. When enabled JNDI only supports the java protocol.
>
> Tag:
> a)  for a new copy do "git clone 
> https://github.com/apache/logging-log4j2.git"; and then "git checkout 
> tags/log4j-2.12.2-rc1”  or just "git clone -b log4j-2.12.2-rc1 
> https://github.com/apache/logging-log4j2.git";
> b) for an existing working copy to “git pull” and then “git checkout 
> tags/log4j-2.12.2-rc1”
>
> Web Site:  No web site was generated for this release. The 2.16.0 web site 
> will be updated appropriately.
>
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachelogging-1070
>
> 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-1070/org/apache/logging/log4j/

[VOTE] Release Log4j 2.12.2-rc1

This is a vote to release Log4j 2.12.2, a security release for Java 7 users.

Please download, test, and cast your votes on the log4j developers list.
[] +1, release the artifacts
[] -1, don't release because...

The vote will remain open for as short amount as time as required to vet the
release. 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 version include:

Fixed Bugs

• LOG4J-3220: Disable JNDI by default, remove JNDI Lookup, remove
message lookups. When enabled JNDI only supports the java protocol.

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

Web Site: No web site was generated for this release. The 2.16.0 web site will
be updated appropriately.

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

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-1070/org/apache/logging/log4j/

[VOTE] Release Log4j Kotlin API 1.2.0-rc1

This is a vote to release Log4j Kotlin API version 1.2.0, the next version of
the Kotlin facade for Log4j2.

Please download, test, and cast your votes on the log4j developers list.
[] +1, release the artifacts
[] -1, don't release because...

The vote will remain open for 24 hours (or more if 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 votesand more positive
than negative votes are required.

Changes in this release include:

* LOG4J2-3218: Update Log4j dependency to 2.16.0.

This is primarily provided to help upgrade transitive dependencies on
log4j-core which was recently updated to fix CVE-2021-44228.

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

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

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

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

--
Matt Sicker

Re: LOG4J2-3213 CVE missing CPE information in NVD

I did not fix that. As for how they’re made, I found the CPE database and 
searched for log4j to find the existing strings.

As for editing CVEs, that’s through this site: https://cveprocess.apache.org/
--
Matt Sicker

> On Dec 13, 2021, at 16:04, Volkan Yazıcı  wrote:
> 
> Matt, I see that it is fixed in
> https://nvd.nist.gov/vuln/detail/CVE-2021-44228
> Did you do it? If so,
> 1. How did you come up with CPEs?
> 2. How did you edit the CVE?
> 
> 
> On Mon, Dec 13, 2021 at 6:50 PM Matt Sicker  wrote:
> 
>> Based on existing CPEs, I think it would look something like:
>> 
>> cpe:2.3:a:apache:log4j:*:*:*:*:*:*:*:* up to version 2.14.1 are affected.
>> 
>> On Mon, Dec 13, 2021 at 3:31 AM Volkan Yazıcı  wrote:
>>> 
>>> Mind somebody helping with LOG4J2-3213
>>> , please? I have no
>> idea
>>> how this entire CVE process is managed and updated. I would appreciate it
>>> if the one who performs the correction can also share how he/she did
>> that.
>>> So that next time first-timers like me can also help.
>>

Re: Re: Regarding the resolution for the latest vulnerability

Our latest release, 2.16.0, completely removes the message lookup
functionality which makes it impossible to inadvertently re-enable.

On Mon, Dec 13, 2021 at 4:58 PM Dash a  wrote:
>
> Hello,
> Thanks for the explanation. It is a bit more relaxing.
>
> As for current concerns - upon a bit of thought i see it as concerning if
> the current implementation doesn't warn the user when it is enabled.
>
> This can present issue in auditing or false negative result in case of
> supply chain attack/lookalikes or a vendor obscuring insecure app design.
>
> of course this will depend on the complexity of the auditing software but
> in cases such as  containers or ready made appliances they already quite
> hard to audit from that angle  and ease the auditing process will be
> welcomed
>
>
> Daniel.

RE: Re: Regarding the resolution for the latest vulnerability

2021-12-13 Thread Dash a

Hello,
Thanks for the explanation. It is a bit more relaxing.

As for current concerns - upon a bit of thought i see it as concerning if
the current implementation doesn't warn the user when it is enabled.

This can present issue in auditing or false negative result in case of
supply chain attack/lookalikes or a vendor obscuring insecure app design.

of course this will depend on the complexity of the auditing software but
in cases such as  containers or ready made appliances they already quite
hard to audit from that angle  and ease the auditing process will be
welcomed


Daniel.

[ANNOUNCE] Apache Log4j 2.16.0 Released

The Apache Log4j 2 team is pleased to announce the Log4j 2.16.0 release!

Apache Log4j is a well known framework for logging application
behavior. Log4j 2 is an upgrade to Log4j that provides significant
improvements over its predecessor, Log4j 1.x, and provides many other
modern features such as support for Markers, lambda expressions for
lazy logging, property substitution using Lookups, multiple patterns
on a PatternLayout and asynchronous Loggers. Another notable Log4j 2
feature is the ability to be "garbage-free" (avoid allocating
temporary objects) while logging. In addition, Log4j 2 will not lose
events while reconfiguring.

The artifacts may be downloaded from
https://logging.apache.org/log4j/2.x/download.html.

This release contains one change which is noted below.

Due to a break in compatibility in the SLF4J binding, Log4j now ships
with two versions of the SLF4J to Log4j adapters. log4j-slf4j-impl
should be used with SLF4J 1.7.x and earlier and log4j-slf4j18-impl
should be used with SLF4J 1.8.x and later. SLF4J-2.0.0 alpha releases
are not fully supported. See
https://issues.apache.org/jira/browse/LOG4J2-2975 and
https://jira.qos.ch/browse/SLF4J-511.

Some of the changes in Log4j 2.16.0 include:

* Removed Message Lookups. This is a hardening related to changes made
to prevent CVE-2021-44228. While this change is recommended, it is NOT
required to fix CVE-2021-44228.
* While release 2.15.0 removed the ability to resolve Lookups and log
messages and addressed issues with how JNDI is accessed, the Log4j
team feels that having JNDI enabled by default introduces an undue
risk for our users. Starting in version 2.16.0, JNDI functionality is
disabled by default and can be re-enabled via the log4j2.enableJndi
system property. Use of JNDI in an unprotected context is a large
security risk and should be treated as such in both this library and
all other Java libraries using JNDI.
* Prior to version 2.15.0, Log4j would automatically resolve Lookups
contained in the message or its parameters in the Pattern Layout. This
behavior is no longer the default and must be enabled by specifying
%msg{lookup}.

The Log4j 2.16.0 API, as well as many core components, maintains
binary compatibility with previous releases. This version is
recommended as an upgrade

GA Release 2.16.0

Changes in this version 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.



Apache Log4j 2.16.0 requires a minimum of Java 8 to build and run.
Log4j 2.12.1 is the last release to support Java 7. Java 7 is no
longer supported by the Log4j team.

For complete information on Apache Log4j 2, including instructions on
how to submit bug reports, patches, or suggestions for improvement,
see the Apache Apache Log4j 2 website:

https://logging.apache.org/log4j/2.x/

-- 
Matt Sicker
PMC Member, Logging Services, Apache Software Foundation

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

Darn! I have remarked this discrepancy in 2.16.0-rc1 voting!

On Mon, Dec 13, 2021 at 8:51 PM Gary Gregory  wrote:

> Wouldn't this be better:
>
> diff --git
>
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/Interpolator.java
>
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/Interpolator.java
> index 75c0a45..9c491ac 100644
> ---
>
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/Interpolator.java
> +++
>
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/Interpolator.java
> @@ -78,7 +78,7 @@
>  for (final Map.Entry> entry :
> plugins.entrySet()) {
>  try {
>  final Class clazz =
> entry.getValue().getPluginClass().asSubclass(StrLookup.class);
> -if (!clazz.getName().equals(JndiLookup.class.getName()) ||
> JndiManager.isJndiEnabled()) {
> +if
> (!clazz.getName().equals("org.apache.logging.log4j.core.lookup.JndiLookup")
> || JndiManager.isJndiEnabled()) {
>  strLookupMap.put(entry.getKey().toLowerCase(),
> ReflectionUtil.instantiate(clazz));
>  }
>  } catch (final Throwable t) {
>
> ?
>
> On Mon, Dec 13, 2021 at 2:48 PM Gary Gregory 
> wrote:
>
> > zip -q -d log4j-core-*.jar
> > org/apache/logging/log4j/core/lookup/JndiLookup.class
> >
> > This can't be right, can it?
> >
> > We have a hard reference to that class
> > in org.apache.logging.log4j.core.lookup.Interpolator
> >
> > Should we really recommend this?
> >
> > Gary
> >
>

Re: LOG4J2-3213 CVE missing CPE information in NVD

Matt, I see that it is fixed in
https://nvd.nist.gov/vuln/detail/CVE-2021-44228
Did you do it? If so,
1. How did you come up with CPEs?
2. How did you edit the CVE?


On Mon, Dec 13, 2021 at 6:50 PM Matt Sicker  wrote:

> Based on existing CPEs, I think it would look something like:
>
> cpe:2.3:a:apache:log4j:*:*:*:*:*:*:*:* up to version 2.14.1 are affected.
>
> On Mon, Dec 13, 2021 at 3:31 AM Volkan Yazıcı  wrote:
> >
> > Mind somebody helping with LOG4J2-3213
> > , please? I have no
> idea
> > how this entire CVE process is managed and updated. I would appreciate it
> > if the one who performs the correction can also share how he/she did
> that.
> > So that next time first-timers like me can also help.
>

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

Well, the mitigation of deleting the file is for older releases, not
the current ones, right?

On Mon, Dec 13, 2021 at 1:53 PM Gary Gregory  wrote:
>
> Never mind, that hard reference is from 2 days ago... BUT... if someone
> decides to apply this command to a current version, not so good.
>
> Gary
>
> On Mon, Dec 13, 2021 at 2:51 PM Gary Gregory  wrote:
>
> > Wouldn't this be better:
> >
> > diff --git
> > a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/Interpolator.java
> > b/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/Interpolator.java
> > index 75c0a45..9c491ac 100644
> > ---
> > a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/Interpolator.java
> > +++
> > b/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/Interpolator.java
> > @@ -78,7 +78,7 @@
> >  for (final Map.Entry> entry :
> > plugins.entrySet()) {
> >  try {
> >  final Class clazz =
> > entry.getValue().getPluginClass().asSubclass(StrLookup.class);
> > -if (!clazz.getName().equals(JndiLookup.class.getName())
> > || JndiManager.isJndiEnabled()) {
> > +if
> > (!clazz.getName().equals("org.apache.logging.log4j.core.lookup.JndiLookup")
> > || JndiManager.isJndiEnabled()) {
> >  strLookupMap.put(entry.getKey().toLowerCase(),
> > ReflectionUtil.instantiate(clazz));
> >  }
> >  } catch (final Throwable t) {
> >
> > ?
> >
> > On Mon, Dec 13, 2021 at 2:48 PM Gary Gregory 
> > wrote:
> >
> >> zip -q -d log4j-core-*.jar
> >> org/apache/logging/log4j/core/lookup/JndiLookup.class
> >>
> >> This can't be right, can it?
> >>
> >> We have a hard reference to that class
> >> in org.apache.logging.log4j.core.lookup.Interpolator
> >>
> >> Should we really recommend this?
> >>
> >> Gary
> >>
> >

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

Never mind, that hard reference is from 2 days ago... BUT... if someone
decides to apply this command to a current version, not so good.

Gary

On Mon, Dec 13, 2021 at 2:51 PM Gary Gregory  wrote:

> Wouldn't this be better:
>
> diff --git
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/Interpolator.java
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/Interpolator.java
> index 75c0a45..9c491ac 100644
> ---
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/Interpolator.java
> +++
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/Interpolator.java
> @@ -78,7 +78,7 @@
>  for (final Map.Entry> entry :
> plugins.entrySet()) {
>  try {
>  final Class clazz =
> entry.getValue().getPluginClass().asSubclass(StrLookup.class);
> -if (!clazz.getName().equals(JndiLookup.class.getName())
> || JndiManager.isJndiEnabled()) {
> +if
> (!clazz.getName().equals("org.apache.logging.log4j.core.lookup.JndiLookup")
> || JndiManager.isJndiEnabled()) {
>  strLookupMap.put(entry.getKey().toLowerCase(),
> ReflectionUtil.instantiate(clazz));
>  }
>  } catch (final Throwable t) {
>
> ?
>
> On Mon, Dec 13, 2021 at 2:48 PM Gary Gregory 
> wrote:
>
>> zip -q -d log4j-core-*.jar
>> org/apache/logging/log4j/core/lookup/JndiLookup.class
>>
>> This can't be right, can it?
>>
>> We have a hard reference to that class
>> in org.apache.logging.log4j.core.lookup.Interpolator
>>
>> Should we really recommend this?
>>
>> Gary
>>
>

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

Wouldn't this be better:

diff --git
a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/Interpolator.java
b/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/Interpolator.java
index 75c0a45..9c491ac 100644
---
a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/Interpolator.java
+++
b/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/Interpolator.java
@@ -78,7 +78,7 @@
 for (final Map.Entry> entry :
plugins.entrySet()) {
 try {
 final Class clazz =
entry.getValue().getPluginClass().asSubclass(StrLookup.class);
-if (!clazz.getName().equals(JndiLookup.class.getName()) ||
JndiManager.isJndiEnabled()) {
+if
(!clazz.getName().equals("org.apache.logging.log4j.core.lookup.JndiLookup")
|| JndiManager.isJndiEnabled()) {
 strLookupMap.put(entry.getKey().toLowerCase(),
ReflectionUtil.instantiate(clazz));
 }
 } catch (final Throwable t) {

?

On Mon, Dec 13, 2021 at 2:48 PM Gary Gregory  wrote:

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

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

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

This can't be right, can it?

We have a hard reference to that class
in org.apache.logging.log4j.core.lookup.Interpolator

Should we really recommend this?

Gary

Re: [VOTE] Release Log4j 2.15.1-rc1

2021-12-13 Thread Mikael Ståldal

I agree too. I was just worried that we wouldn't remove Message Lookups 
until 3.x. Removing them in the next minor release (2.16.0) is reasonable.



On 2021-12-13 10:12, Volkan Yazıcı wrote:

I agree with both of your points Remko.

On Mon, Dec 13, 2021 at 2:40 AM Remko Popma  wrote:


I am also 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.

[] +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. A

Re: [VOTE] Release Log4j 2.16.0-rc1

2021-12-13 Thread Ron Grabowski

I saw the vote has already been closed on log4j-2.16.0-rc1, +1 from me 
for completeness. No cassandra errors with rat:check this time:


mvn clean install -t toolchains-sample-win.xml
mvn revapi:check -pl log4j-api
mvn apache-rat:check

Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: C:\projects\apache-maven-3.8.4
Java version: 1.8.0_181, vendor: Oracle Corporation, runtime: C:\Program 
Files\Java\jdk1.8.0_181\jre

Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

On 12/13/2021 8:04 AM, Gary Gregory wrote:

+1

mvn clean package
mvn apache-rat:check

Is this command 'wrong'?
mvn revapi:check -pl log4j-api
I get errors.

My Maven toolchain file contains mappings for Java 8, 11, 17.

Same failure as before on Windows 10 and Java 8 in the restricted JNDI
test. Could be something odd with my set up I suppose.

Darwin gdg-mac-mini.local 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

openjdk version "1.8.0_312"
OpenJDK Runtime Environment (build 1.8.0_312-bre_2021_10_20_23_15-b00)
OpenJDK 64-Bit Server VM (build 25.312-b00, mixed mode)

Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /usr/local/Cellar/maven/3.8.4/libexec
Java version: 1.8.0_312, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk@8/1.8.0+312/libexec/openjdk.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "12.0.1", arch: "x86_64", family: "mac"

Gary


On Mon, Dec 13, 2021 at 6:22 AM Remko Popma  wrote:


+1 build succeeds and tests all pass

Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
2019-08-28T00:06:16+09:00)
Maven home: C:\apps\apache-maven-3.6.2\bin\..
Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
C:\apps\jdk1.8.0_202\jre
Default locale: en_GB, platform encoding: MS932
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

On Mon, Dec 13, 2021 at 7:19 PM Volkan Yazıcı  wrote:


+1

`./mvnw verify` on `log4j-2.16.0-rc1` branch passes with the following
setup:

$ java -version
openjdk version "1.8.0_312"
OpenJDK Runtime Environment (Zulu 8.58.0.13-CA-linux64) (build
1.8.0_312-b07)
OpenJDK 64-Bit Server VM (Zulu 8.58.0.13-CA-linux64) (build 25.312-b07,
mixed mode)

$ java -version
openjdk version "17.0.1" 2021-10-19 LTS
OpenJDK Runtime Environment Zulu17.30+15-CA (build 17.0.1+12-LTS)
OpenJDK 64-Bit Server VM Zulu17.30+15-CA (build 17.0.1+12-LTS, mixed

mode,

sharing)

$ uname -a
Linux tahta 5.11.0-41-generic #45~20.04.1-Ubuntu SMP Wed Nov 10 10:20:10
UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Though I would appreciate some small fixes, which can be incorporated

later

on as well:

1. index.md.vm contains references to 2.15.1 and misses Remko's
improvements in LOG4J2-3214

2. security.md needs to be aligned with LOG4J2-3214
 too
3. appenders.xml contains references to 2.15.1
4. lookups.xml contains references to 2.15.1
5. I want a link to myself in support.md too!
6. I have encountered multiple occurrences of *"release contains one
change"* phrase, yet there are actually two changes. I would rather
rephrase this as *"release contains a limited set of changes focusing

on

security"*.
7. I have seen that CassandraAppenderIT is disabled due to aarch64
failures. I would appreciate a ticket for incorporating a
@DisabledOnArch
annotation.
8. In Interpolator.java, there are usages of
`JndiLookup.class.getName()` and
`"org.apache.logging.log4j.core.lookup.JndiLookup"`, I'd settle on

one.

9. JNDI changes look good to me, great job Ralph!
10. I am baffled to see that SimplePerfTest.bubbleSort() was broken,

yet

tests were passing! (Thanks Matt!)

I can actually incorporate website fixes. What is the procedure for that?
Create a `release-2.16.0` branch derived from `log4j-2.16.0-rc1` tag and
commit changes there?

On Mon, Dec 13, 2021 at 9:02 AM Ralph Goers 
wrote:


+1

Verified the signature and the SHA512 hashes. Verified the build worked
for me. I did correct some mistakes in the staging site home page news
section as it still referenced 2.15.1.

Ralph



On Dec 12, 2021, at 11:18 PM, Matt Sicker  wrote:

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

Re: LOG4J2-3213 CVE missing CPE information in NVD

Based on existing CPEs, I think it would look something like:

cpe:2.3:a:apache:log4j:*:*:*:*:*:*:*:* up to version 2.14.1 are affected.

On Mon, Dec 13, 2021 at 3:31 AM Volkan Yazıcı  wrote:
>
> Mind somebody helping with LOG4J2-3213
> , please? I have no idea
> how this entire CVE process is managed and updated. I would appreciate it
> if the one who performs the correction can also share how he/she did that.
> So that next time first-timers like me can also help.

[VOTE][RESULT] Release Log4j 2.16.0-rc1

And my +1. This makes 5 +1 votes, no -1 votes. I’ll continue with the release.
--
Matt Sicker

> On Dec 13, 2021, at 09:30, Gary Gregory  wrote:
> 
> Depending on the RM's availability, I think we can proceed here.
> 
> Gary
> 
> On Mon, Dec 13, 2021 at 10:30 AM Gary Gregory 
> wrote:
> 
>> Depending on the RM's availability
>> 
>> On Mon, Dec 13, 2021 at 8:04 AM Gary Gregory 
>> wrote:
>> 
>>> +1
>>> 
>>> mvn clean package
>>> mvn apache-rat:check
>>> 
>>> Is this command 'wrong'?
>>> mvn revapi:check -pl log4j-api
>>> I get errors.
>>> 
>>> My Maven toolchain file contains mappings for Java 8, 11, 17.
>>> 
>>> Same failure as before on Windows 10 and Java 8 in the restricted JNDI
>>> test. Could be something odd with my set up I suppose.
>>> 
>>> Darwin gdg-mac-mini.local 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
>>> 
>>> openjdk version "1.8.0_312"
>>> OpenJDK Runtime Environment (build 1.8.0_312-bre_2021_10_20_23_15-b00)
>>> OpenJDK 64-Bit Server VM (build 25.312-b00, mixed mode)
>>> 
>>> Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
>>> Maven home: /usr/local/Cellar/maven/3.8.4/libexec
>>> Java version: 1.8.0_312, vendor: Homebrew, runtime:
>>> /usr/local/Cellar/openjdk@8
>>> /1.8.0+312/libexec/openjdk.jdk/Contents/Home/jre
>>> Default locale: en_US, platform encoding: UTF-8
>>> OS name: "mac os x", version: "12.0.1", arch: "x86_64", family: "mac"
>>> 
>>> Gary
>>> 
>>> 
>>> On Mon, Dec 13, 2021 at 6:22 AM Remko Popma 
>>> wrote:
>>> 
 +1 build succeeds and tests all pass
 
 Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
 2019-08-28T00:06:16+09:00)
 Maven home: C:\apps\apache-maven-3.6.2\bin\..
 Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
 C:\apps\jdk1.8.0_202\jre
 Default locale: en_GB, platform encoding: MS932
 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
 
 On Mon, Dec 13, 2021 at 7:19 PM Volkan Yazıcı  wrote:
 
> +1
> 
> `./mvnw verify` on `log4j-2.16.0-rc1` branch passes with the following
> setup:
> 
> $ java -version
> openjdk version "1.8.0_312"
> OpenJDK Runtime Environment (Zulu 8.58.0.13-CA-linux64) (build
> 1.8.0_312-b07)
> OpenJDK 64-Bit Server VM (Zulu 8.58.0.13-CA-linux64) (build 25.312-b07,
> mixed mode)
> 
> $ java -version
> openjdk version "17.0.1" 2021-10-19 LTS
> OpenJDK Runtime Environment Zulu17.30+15-CA (build 17.0.1+12-LTS)
> OpenJDK 64-Bit Server VM Zulu17.30+15-CA (build 17.0.1+12-LTS, mixed
 mode,
> sharing)
> 
> $ uname -a
> Linux tahta 5.11.0-41-generic #45~20.04.1-Ubuntu SMP Wed Nov 10
 10:20:10
> UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
> 
> Though I would appreciate some small fixes, which can be incorporated
 later
> on as well:
> 
>   1. index.md.vm contains references to 2.15.1 and misses Remko's
>   improvements in LOG4J2-3214
>   
>   2. security.md needs to be aligned with LOG4J2-3214
>    too
>   3. appenders.xml contains references to 2.15.1
>   4. lookups.xml contains references to 2.15.1
>   5. I want a link to myself in support.md too!
>   6. I have encountered multiple occurrences of *"release contains one
>   change"* phrase, yet there are actually two changes. I would rather
>   rephrase this as *"release contains a limited set of changes
 focusing on
>   security"*.
>   7. I have seen that CassandraAppenderIT is disabled due to aarch64
>   failures. I would appreciate a ticket for incorporating a
> @DisabledOnArch
>   annotation.
>   8. In Interpolator.java, there are usages of
>   `JndiLookup.class.getName()` and
>   `"org.apache.logging.log4j.core.lookup.JndiLookup"`, I'd settle on
 one.
>   9. JNDI changes look good to me, great job Ralph!
>   10. I am baffled to see that SimplePerfTest.bubbleSort() was
 broken, yet
>   tests were passing! (Thanks Matt!)
> 
> I can actually incorporate website fixes. What is the procedure for
 that?
> Create a `release-2.16.0` branch derived from `log4j-2.16.0-rc1` tag
 and
> commit changes there?
> 
> On Mon, Dec 13, 2021 at 9:02 AM Ralph Goers <
 ralph.go...@dslextreme.com>
> wrote:
> 
>> +1
>> 
>> Verified the signature and the SHA512 hashes. Verified the build
 worked
>> for me. I did correct some mistakes in the staging site home page
 news
>> section as it still referenced 2.15.1.
>> 
>> Ralph
>> 
>> 
>>> On Dec 12, 2021, at 11:18 PM, Matt Sicker 
 wrote:
>>> 
>>> This is a vote to release Log4j 2.16.0, the next version of the
 Log4j 2
>> project.
>>> 
>>> Please download, test, and cast your v

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

Description:

JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data 
when the attacker has write access to the Log4j configuration. The attacker can 
provide TopicBindingName and TopicConnectionFactoryBindingName configurations 
causing JMSAppender to perform JNDI requests that result in remote code 
execution in a similar fashion to CVE-2021-44228.  

Note this issue only affects Log4j 1.2 when specifically configured to use 
JMSAppender, which is not the default.

Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to 
Log4j 2 as it addresses numerous other issues from the previous versions.

References:

https://www.cve.org/CVERecord?id=CVE-2021-44228
https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126
https://access.redhat.com/security/cve/CVE-2021-4104

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

1.2 has been EOL for years so it has not received any attention, but the
JMS Appender is the only one that uses the JNDI API in 1.2, so it should be
OK otherwise.

Gary

On Mon, Dec 13, 2021 at 10:55 AM GitBox  wrote:

>
> sushain-pandit commented on pull request #608:
> URL:
> https://github.com/apache/logging-log4j2/pull/608#issuecomment-992617101
>
>
>> > @asokolov-flex
>> > Log4J 1.2.17 is only (potentially) vulnerable if you choose to use
> the JMS Appender. If you are, you will have to migrate to Log4J2 / Logback.
>>
>> If you use the JMS Appender AND you configure it with JNDI. If you
> configure logback with JMS and JNDI, I am guessing you'll have the same
> issue.
>
>Apologies if this has been ans prior: re log4j 1.2.17, is it a
> certainty that the only appender with the issue is JMS?
>
>
> --
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
>
> To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>
>

Re: [VOTE] Release Log4j 2.16.0-rc1

Depending on the RM's availability, I think we can proceed here.

Gary

On Mon, Dec 13, 2021 at 10:30 AM Gary Gregory 
wrote:

> Depending on the RM's availability
>
> On Mon, Dec 13, 2021 at 8:04 AM Gary Gregory 
> wrote:
>
>> +1
>>
>> mvn clean package
>> mvn apache-rat:check
>>
>> Is this command 'wrong'?
>> mvn revapi:check -pl log4j-api
>> I get errors.
>>
>> My Maven toolchain file contains mappings for Java 8, 11, 17.
>>
>> Same failure as before on Windows 10 and Java 8 in the restricted JNDI
>> test. Could be something odd with my set up I suppose.
>>
>> Darwin gdg-mac-mini.local 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
>>
>> openjdk version "1.8.0_312"
>> OpenJDK Runtime Environment (build 1.8.0_312-bre_2021_10_20_23_15-b00)
>> OpenJDK 64-Bit Server VM (build 25.312-b00, mixed mode)
>>
>> Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
>> Maven home: /usr/local/Cellar/maven/3.8.4/libexec
>> Java version: 1.8.0_312, vendor: Homebrew, runtime:
>> /usr/local/Cellar/openjdk@8
>> /1.8.0+312/libexec/openjdk.jdk/Contents/Home/jre
>> Default locale: en_US, platform encoding: UTF-8
>> OS name: "mac os x", version: "12.0.1", arch: "x86_64", family: "mac"
>>
>> Gary
>>
>>
>> On Mon, Dec 13, 2021 at 6:22 AM Remko Popma 
>> wrote:
>>
>>> +1 build succeeds and tests all pass
>>>
>>> Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
>>> 2019-08-28T00:06:16+09:00)
>>> Maven home: C:\apps\apache-maven-3.6.2\bin\..
>>> Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
>>> C:\apps\jdk1.8.0_202\jre
>>> Default locale: en_GB, platform encoding: MS932
>>> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>>>
>>> On Mon, Dec 13, 2021 at 7:19 PM Volkan Yazıcı  wrote:
>>>
>>> > +1
>>> >
>>> > `./mvnw verify` on `log4j-2.16.0-rc1` branch passes with the following
>>> > setup:
>>> >
>>> > $ java -version
>>> > openjdk version "1.8.0_312"
>>> > OpenJDK Runtime Environment (Zulu 8.58.0.13-CA-linux64) (build
>>> > 1.8.0_312-b07)
>>> > OpenJDK 64-Bit Server VM (Zulu 8.58.0.13-CA-linux64) (build 25.312-b07,
>>> > mixed mode)
>>> >
>>> > $ java -version
>>> > openjdk version "17.0.1" 2021-10-19 LTS
>>> > OpenJDK Runtime Environment Zulu17.30+15-CA (build 17.0.1+12-LTS)
>>> > OpenJDK 64-Bit Server VM Zulu17.30+15-CA (build 17.0.1+12-LTS, mixed
>>> mode,
>>> > sharing)
>>> >
>>> > $ uname -a
>>> > Linux tahta 5.11.0-41-generic #45~20.04.1-Ubuntu SMP Wed Nov 10
>>> 10:20:10
>>> > UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
>>> >
>>> > Though I would appreciate some small fixes, which can be incorporated
>>> later
>>> > on as well:
>>> >
>>> >1. index.md.vm contains references to 2.15.1 and misses Remko's
>>> >improvements in LOG4J2-3214
>>> >
>>> >2. security.md needs to be aligned with LOG4J2-3214
>>> > too
>>> >3. appenders.xml contains references to 2.15.1
>>> >4. lookups.xml contains references to 2.15.1
>>> >5. I want a link to myself in support.md too!
>>> >6. I have encountered multiple occurrences of *"release contains one
>>> >change"* phrase, yet there are actually two changes. I would rather
>>> >rephrase this as *"release contains a limited set of changes
>>> focusing on
>>> >security"*.
>>> >7. I have seen that CassandraAppenderIT is disabled due to aarch64
>>> >failures. I would appreciate a ticket for incorporating a
>>> > @DisabledOnArch
>>> >annotation.
>>> >8. In Interpolator.java, there are usages of
>>> >`JndiLookup.class.getName()` and
>>> >`"org.apache.logging.log4j.core.lookup.JndiLookup"`, I'd settle on
>>> one.
>>> >9. JNDI changes look good to me, great job Ralph!
>>> >10. I am baffled to see that SimplePerfTest.bubbleSort() was
>>> broken, yet
>>> >tests were passing! (Thanks Matt!)
>>> >
>>> > I can actually incorporate website fixes. What is the procedure for
>>> that?
>>> > Create a `release-2.16.0` branch derived from `log4j-2.16.0-rc1` tag
>>> and
>>> > commit changes there?
>>> >
>>> > On Mon, Dec 13, 2021 at 9:02 AM Ralph Goers <
>>> ralph.go...@dslextreme.com>
>>> > wrote:
>>> >
>>> > > +1
>>> > >
>>> > > Verified the signature and the SHA512 hashes. Verified the build
>>> worked
>>> > > for me. I did correct some mistakes in the staging site home page
>>> news
>>> > > section as it still referenced 2.15.1.
>>> > >
>>> > > Ralph
>>> > >
>>> > >
>>> > > > On Dec 12, 2021, at 11:18 PM, Matt Sicker 
>>> wrote:
>>> > > >
>>> > > > This is a vote to release Log4j 2.16.0, the 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

Re: [VOTE] Release Log4j 2.16.0-rc1

Depending on the RM's availability

On Mon, Dec 13, 2021 at 8:04 AM Gary Gregory  wrote:

> +1
>
> mvn clean package
> mvn apache-rat:check
>
> Is this command 'wrong'?
> mvn revapi:check -pl log4j-api
> I get errors.
>
> My Maven toolchain file contains mappings for Java 8, 11, 17.
>
> Same failure as before on Windows 10 and Java 8 in the restricted JNDI
> test. Could be something odd with my set up I suppose.
>
> Darwin gdg-mac-mini.local 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
>
> openjdk version "1.8.0_312"
> OpenJDK Runtime Environment (build 1.8.0_312-bre_2021_10_20_23_15-b00)
> OpenJDK 64-Bit Server VM (build 25.312-b00, mixed mode)
>
> Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
> Maven home: /usr/local/Cellar/maven/3.8.4/libexec
> Java version: 1.8.0_312, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@8
> /1.8.0+312/libexec/openjdk.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "12.0.1", arch: "x86_64", family: "mac"
>
> Gary
>
>
> On Mon, Dec 13, 2021 at 6:22 AM Remko Popma  wrote:
>
>> +1 build succeeds and tests all pass
>>
>> Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
>> 2019-08-28T00:06:16+09:00)
>> Maven home: C:\apps\apache-maven-3.6.2\bin\..
>> Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
>> C:\apps\jdk1.8.0_202\jre
>> Default locale: en_GB, platform encoding: MS932
>> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>>
>> On Mon, Dec 13, 2021 at 7:19 PM Volkan Yazıcı  wrote:
>>
>> > +1
>> >
>> > `./mvnw verify` on `log4j-2.16.0-rc1` branch passes with the following
>> > setup:
>> >
>> > $ java -version
>> > openjdk version "1.8.0_312"
>> > OpenJDK Runtime Environment (Zulu 8.58.0.13-CA-linux64) (build
>> > 1.8.0_312-b07)
>> > OpenJDK 64-Bit Server VM (Zulu 8.58.0.13-CA-linux64) (build 25.312-b07,
>> > mixed mode)
>> >
>> > $ java -version
>> > openjdk version "17.0.1" 2021-10-19 LTS
>> > OpenJDK Runtime Environment Zulu17.30+15-CA (build 17.0.1+12-LTS)
>> > OpenJDK 64-Bit Server VM Zulu17.30+15-CA (build 17.0.1+12-LTS, mixed
>> mode,
>> > sharing)
>> >
>> > $ uname -a
>> > Linux tahta 5.11.0-41-generic #45~20.04.1-Ubuntu SMP Wed Nov 10 10:20:10
>> > UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
>> >
>> > Though I would appreciate some small fixes, which can be incorporated
>> later
>> > on as well:
>> >
>> >1. index.md.vm contains references to 2.15.1 and misses Remko's
>> >improvements in LOG4J2-3214
>> >
>> >2. security.md needs to be aligned with LOG4J2-3214
>> > too
>> >3. appenders.xml contains references to 2.15.1
>> >4. lookups.xml contains references to 2.15.1
>> >5. I want a link to myself in support.md too!
>> >6. I have encountered multiple occurrences of *"release contains one
>> >change"* phrase, yet there are actually two changes. I would rather
>> >rephrase this as *"release contains a limited set of changes
>> focusing on
>> >security"*.
>> >7. I have seen that CassandraAppenderIT is disabled due to aarch64
>> >failures. I would appreciate a ticket for incorporating a
>> > @DisabledOnArch
>> >annotation.
>> >8. In Interpolator.java, there are usages of
>> >`JndiLookup.class.getName()` and
>> >`"org.apache.logging.log4j.core.lookup.JndiLookup"`, I'd settle on
>> one.
>> >9. JNDI changes look good to me, great job Ralph!
>> >10. I am baffled to see that SimplePerfTest.bubbleSort() was broken,
>> yet
>> >tests were passing! (Thanks Matt!)
>> >
>> > I can actually incorporate website fixes. What is the procedure for
>> that?
>> > Create a `release-2.16.0` branch derived from `log4j-2.16.0-rc1` tag and
>> > commit changes there?
>> >
>> > On Mon, Dec 13, 2021 at 9:02 AM Ralph Goers > >
>> > wrote:
>> >
>> > > +1
>> > >
>> > > Verified the signature and the SHA512 hashes. Verified the build
>> worked
>> > > for me. I did correct some mistakes in the staging site home page news
>> > > section as it still referenced 2.15.1.
>> > >
>> > > Ralph
>> > >
>> > >
>> > > > On Dec 12, 2021, at 11:18 PM, Matt Sicker  wrote:
>> > > >
>> > > > This is a vote to release Log4j 2.16.0, the 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
>> > >

Re: [VOTE] Release Log4j 2.16.0-rc1

+1

mvn clean package
mvn apache-rat:check

Is this command 'wrong'?
mvn revapi:check -pl log4j-api
I get errors.

My Maven toolchain file contains mappings for Java 8, 11, 17.

Same failure as before on Windows 10 and Java 8 in the restricted JNDI
test. Could be something odd with my set up I suppose.

Darwin gdg-mac-mini.local 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

openjdk version "1.8.0_312"
OpenJDK Runtime Environment (build 1.8.0_312-bre_2021_10_20_23_15-b00)
OpenJDK 64-Bit Server VM (build 25.312-b00, mixed mode)

Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /usr/local/Cellar/maven/3.8.4/libexec
Java version: 1.8.0_312, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk@8/1.8.0+312/libexec/openjdk.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "12.0.1", arch: "x86_64", family: "mac"

Gary


On Mon, Dec 13, 2021 at 6:22 AM Remko Popma  wrote:

> +1 build succeeds and tests all pass
>
> Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
> 2019-08-28T00:06:16+09:00)
> Maven home: C:\apps\apache-maven-3.6.2\bin\..
> Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
> C:\apps\jdk1.8.0_202\jre
> Default locale: en_GB, platform encoding: MS932
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>
> On Mon, Dec 13, 2021 at 7:19 PM Volkan Yazıcı  wrote:
>
> > +1
> >
> > `./mvnw verify` on `log4j-2.16.0-rc1` branch passes with the following
> > setup:
> >
> > $ java -version
> > openjdk version "1.8.0_312"
> > OpenJDK Runtime Environment (Zulu 8.58.0.13-CA-linux64) (build
> > 1.8.0_312-b07)
> > OpenJDK 64-Bit Server VM (Zulu 8.58.0.13-CA-linux64) (build 25.312-b07,
> > mixed mode)
> >
> > $ java -version
> > openjdk version "17.0.1" 2021-10-19 LTS
> > OpenJDK Runtime Environment Zulu17.30+15-CA (build 17.0.1+12-LTS)
> > OpenJDK 64-Bit Server VM Zulu17.30+15-CA (build 17.0.1+12-LTS, mixed
> mode,
> > sharing)
> >
> > $ uname -a
> > Linux tahta 5.11.0-41-generic #45~20.04.1-Ubuntu SMP Wed Nov 10 10:20:10
> > UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
> >
> > Though I would appreciate some small fixes, which can be incorporated
> later
> > on as well:
> >
> >1. index.md.vm contains references to 2.15.1 and misses Remko's
> >improvements in LOG4J2-3214
> >
> >2. security.md needs to be aligned with LOG4J2-3214
> > too
> >3. appenders.xml contains references to 2.15.1
> >4. lookups.xml contains references to 2.15.1
> >5. I want a link to myself in support.md too!
> >6. I have encountered multiple occurrences of *"release contains one
> >change"* phrase, yet there are actually two changes. I would rather
> >rephrase this as *"release contains a limited set of changes focusing
> on
> >security"*.
> >7. I have seen that CassandraAppenderIT is disabled due to aarch64
> >failures. I would appreciate a ticket for incorporating a
> > @DisabledOnArch
> >annotation.
> >8. In Interpolator.java, there are usages of
> >`JndiLookup.class.getName()` and
> >`"org.apache.logging.log4j.core.lookup.JndiLookup"`, I'd settle on
> one.
> >9. JNDI changes look good to me, great job Ralph!
> >10. I am baffled to see that SimplePerfTest.bubbleSort() was broken,
> yet
> >tests were passing! (Thanks Matt!)
> >
> > I can actually incorporate website fixes. What is the procedure for that?
> > Create a `release-2.16.0` branch derived from `log4j-2.16.0-rc1` tag and
> > commit changes there?
> >
> > On Mon, Dec 13, 2021 at 9:02 AM Ralph Goers 
> > wrote:
> >
> > > +1
> > >
> > > Verified the signature and the SHA512 hashes. Verified the build worked
> > > for me. I did correct some mistakes in the staging site home page news
> > > section as it still referenced 2.15.1.
> > >
> > > Ralph
> > >
> > >
> > > > On Dec 12, 2021, at 11:18 PM, Matt Sicker  wrote:
> > > >
> > > > This is a vote to release Log4j 2.16.0, the 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:

Re: [VOTE] Release Log4j 2.15.1-rc1

JNDI is commonly used to configure JMS and JDBC.

Gary

On Mon, Dec 13, 2021 at 4:12 AM Volkan Yazıcı  wrote:

> Thanks so much for your understanding Ralph, it is very important for me.
>
> For one, message lookups are nothing but a plethora of vulnerabilities. I
> think everybody agrees on this. We shouldn't try to make it secure, we
> _must_ ditch it off.
>
> Second, I think, again, we shouldn't even be trying to incorporate any
> fixes on the JNDI. This approach unfortunately was already proven to be
> futile. We should rather have exposed everywhere how dangerous it is and
> disabled (actually, preferably, removed) it. The entire internet is buzzing
> with JNDI, but I have yet to hear a use case for it. If it would be up to
> me, I would even rollback JndiManager checks introduced in 2.15.0. (I am
> not suggesting this.) All in all, I guess disabling JNDI by default appears
> to be the most sensible next step.
>
> Putting aside all technical details of the next release, we should really
> work on the "human" aspect of things. We should come up with a change set
> to prove the quality of Log4j and win all broken hearts back. This change
> set should shout out loud "we have heard you and thanks for working with
> us!" I don't think we are in a hurry with the next release, let's put some
> diligent effort into what to ship next.
>
> On Mon, Dec 13, 2021 at 12:12 AM 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?

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

It is only used at configuration start, hence I don't think it is needed.
Nevertheless, I have replaced it with Strings.EMPTY_ARRAY.

On Mon, Dec 13, 2021 at 12:39 PM Gary Gregory 
wrote:

> +return new String[0];
>
> This should be a constant.
>
> Gary
>
> On Mon, Dec 13, 2021 at 6:35 AM  wrote:
>
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > vy pushed a commit to branch release-2.x
> > in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
> >
> >
> > The following commit(s) were added to refs/heads/release-2.x by this
> push:
> >  new ad0d0c9  Remove SetUtils from core.
> > ad0d0c9 is described below
> >
> > commit ad0d0c900f75961691eb98065453deca7ade5419
> > Author: Volkan Yazici 
> > AuthorDate: Sun Dec 12 21:14:12 2021 +0100
> >
> > Remove SetUtils from core.
> > ---
> >  log4j-core/revapi.json |  5 +++
> >  .../apache/logging/log4j/core/util/SetUtils.java   | 47
> > --
> >  .../logging/log4j/web/Log4jWebInitializerImpl.java | 40
> +++---
> >  .../logging/log4j/web/Log4jWebInitializerImpl.java | 42
> > ---
> >  4 files changed, 58 insertions(+), 76 deletions(-)
> >
> > diff --git a/log4j-core/revapi.json b/log4j-core/revapi.json
> > index af702c0..95e6d71 100644
> > --- a/log4j-core/revapi.json
> > +++ b/log4j-core/revapi.json
> > @@ -152,6 +152,11 @@
> >  "old": "class
> org.apache.logging.log4j.core.time.MutableInstant",
> >  "new": "class
> org.apache.logging.log4j.core.time.MutableInstant",
> >  "justification": "LOG4J2-3075 MutableInstant extends from
> > TemporalAccessor"
> > +  },
> > +  {
> > +"code": "java.class.removed",
> > +"old": "class org.apache.logging.log4j.core.util.SetUtils",
> > +"justification": "only used by web modules"
> >}
> >  ]
> >}
> > diff --git
> >
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/util/SetUtils.java
> >
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/util/SetUtils.java
> > deleted file mode 100644
> > index e1a5218..000
> > ---
> >
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/util/SetUtils.java
> > +++ /dev/null
> > @@ -1,47 +0,0 @@
> > -/*
> > - * Licensed to the Apache Software Foundation (ASF) under one or more
> > - * contributor license agreements. See the NOTICE file distributed with
> > - * this work for additional information regarding copyright ownership.
> > - * The ASF licenses this file to You under the Apache license, Version
> 2.0
> > - * (the "License"); you may not use this file except in compliance with
> > - * the License. You may obtain a copy of the License at
> > - *
> > - *  http://www.apache.org/licenses/LICENSE-2.0
> > - *
> > - * Unless required by applicable law or agreed to in writing, software
> > - * distributed under the License is distributed on an "AS IS" BASIS,
> > - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> > implied.
> > - * See the license for the specific language governing permissions and
> > - * limitations under the license.
> > - */
> > -package org.apache.logging.log4j.core.util;
> > -
> > -import java.util.Set;
> > -
> > -/**
> > - * Set-related convenience methods.
> > - */
> > -public final class SetUtils {
> > -
> > -private static final String[] EMPTY_STRINGS = new String[0];
> > -
> > -private SetUtils() {}
> > -
> > -/**
> > - * Collects strings starting with the given {@code prefix} from the
> > given {@code set}.
> > - *
> > - * @param set a (nullable) set of strings
> > - * @param prefix a prefix to look for in the string set
> > - * @return an array of the matching strings from the given set
> > - */
> > -public static String[] prefixSet(final Set set, final String
> > prefix) {
> > -if (set == null) {
> > -return EMPTY_STRINGS;
> > -}
> > -return set
> > -.stream()
> > -.filter(string -> string.startsWith(prefix))
> > -.toArray(String[]::new);
> > -}
> > -
> > -}
> > diff --git
> >
> a/log4j-jakarta-web/src/main/java/org/apache/logging/log4j/web/Log4jWebInitializerImpl.java
> >
> b/log4j-jakarta-web/src/main/java/org/apache/logging/log4j/web/Log4jWebInitializerImpl.java
> > index 3ecbe14..5279df9 100644
> > ---
> >
> a/log4j-jakarta-web/src/main/java/org/apache/logging/log4j/web/Log4jWebInitializerImpl.java
> > +++
> >
> b/log4j-jakarta-web/src/main/java/org/apache/logging/log4j/web/Log4jWebInitializerImpl.java
> > @@ -16,19 +16,7 @@
> >   */
> >  package org.apache.logging.log4j.web;
> >
> > -import java.net.URI;
> > -import java.net.URL;
> > -import java.text.SimpleDateFormat;
> > -import java.util.ArrayList;
> > -import java.util.Arrays;
> > -import java.util.Date;
> > -import java.util.List;
> > -import java.util.Map;
> > -import java.util.concurrent.ConcurrentHashMap;
> > -import java.util.co

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

+return new String[0];

This should be a constant.

Gary

On Mon, Dec 13, 2021 at 6:35 AM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> vy pushed a commit to branch release-2.x
> in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
>
>
> The following commit(s) were added to refs/heads/release-2.x by this push:
>  new ad0d0c9  Remove SetUtils from core.
> ad0d0c9 is described below
>
> commit ad0d0c900f75961691eb98065453deca7ade5419
> Author: Volkan Yazici 
> AuthorDate: Sun Dec 12 21:14:12 2021 +0100
>
> Remove SetUtils from core.
> ---
>  log4j-core/revapi.json |  5 +++
>  .../apache/logging/log4j/core/util/SetUtils.java   | 47
> --
>  .../logging/log4j/web/Log4jWebInitializerImpl.java | 40 +++---
>  .../logging/log4j/web/Log4jWebInitializerImpl.java | 42
> ---
>  4 files changed, 58 insertions(+), 76 deletions(-)
>
> diff --git a/log4j-core/revapi.json b/log4j-core/revapi.json
> index af702c0..95e6d71 100644
> --- a/log4j-core/revapi.json
> +++ b/log4j-core/revapi.json
> @@ -152,6 +152,11 @@
>  "old": "class org.apache.logging.log4j.core.time.MutableInstant",
>  "new": "class org.apache.logging.log4j.core.time.MutableInstant",
>  "justification": "LOG4J2-3075 MutableInstant extends from
> TemporalAccessor"
> +  },
> +  {
> +"code": "java.class.removed",
> +"old": "class org.apache.logging.log4j.core.util.SetUtils",
> +"justification": "only used by web modules"
>}
>  ]
>}
> diff --git
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/util/SetUtils.java
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/util/SetUtils.java
> deleted file mode 100644
> index e1a5218..000
> ---
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/util/SetUtils.java
> +++ /dev/null
> @@ -1,47 +0,0 @@
> -/*
> - * Licensed to the Apache Software Foundation (ASF) under one or more
> - * contributor license agreements. See the NOTICE file distributed with
> - * this work for additional information regarding copyright ownership.
> - * The ASF licenses this file to You under the Apache license, Version 2.0
> - * (the "License"); you may not use this file except in compliance with
> - * the License. You may obtain a copy of the License at
> - *
> - *  http://www.apache.org/licenses/LICENSE-2.0
> - *
> - * Unless required by applicable law or agreed to in writing, software
> - * distributed under the License is distributed on an "AS IS" BASIS,
> - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> - * See the license for the specific language governing permissions and
> - * limitations under the license.
> - */
> -package org.apache.logging.log4j.core.util;
> -
> -import java.util.Set;
> -
> -/**
> - * Set-related convenience methods.
> - */
> -public final class SetUtils {
> -
> -private static final String[] EMPTY_STRINGS = new String[0];
> -
> -private SetUtils() {}
> -
> -/**
> - * Collects strings starting with the given {@code prefix} from the
> given {@code set}.
> - *
> - * @param set a (nullable) set of strings
> - * @param prefix a prefix to look for in the string set
> - * @return an array of the matching strings from the given set
> - */
> -public static String[] prefixSet(final Set set, final String
> prefix) {
> -if (set == null) {
> -return EMPTY_STRINGS;
> -}
> -return set
> -.stream()
> -.filter(string -> string.startsWith(prefix))
> -.toArray(String[]::new);
> -}
> -
> -}
> diff --git
> a/log4j-jakarta-web/src/main/java/org/apache/logging/log4j/web/Log4jWebInitializerImpl.java
> b/log4j-jakarta-web/src/main/java/org/apache/logging/log4j/web/Log4jWebInitializerImpl.java
> index 3ecbe14..5279df9 100644
> ---
> a/log4j-jakarta-web/src/main/java/org/apache/logging/log4j/web/Log4jWebInitializerImpl.java
> +++
> b/log4j-jakarta-web/src/main/java/org/apache/logging/log4j/web/Log4jWebInitializerImpl.java
> @@ -16,19 +16,7 @@
>   */
>  package org.apache.logging.log4j.web;
>
> -import java.net.URI;
> -import java.net.URL;
> -import java.text.SimpleDateFormat;
> -import java.util.ArrayList;
> -import java.util.Arrays;
> -import java.util.Date;
> -import java.util.List;
> -import java.util.Map;
> -import java.util.concurrent.ConcurrentHashMap;
> -import java.util.concurrent.TimeUnit;
> -
>  import jakarta.servlet.ServletContext;
> -
>  import org.apache.logging.log4j.LogManager;
>  import org.apache.logging.log4j.core.AbstractLifeCycle;
>  import org.apache.logging.log4j.core.LoggerContext;
> @@ -42,10 +30,16 @@ import
> org.apache.logging.log4j.core.selector.ContextSelector;
>  import org.apache.logging.log4j.core.selector.NamedContextSelector;
>  import org.apache.logging.log4j.core.util.Loader;
>  import org.apache.logging

Re: [VOTE] Release Log4j 2.16.0-rc1

2021-12-13 Thread Remko Popma

+1 build succeeds and tests all pass

Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
2019-08-28T00:06:16+09:00)
Maven home: C:\apps\apache-maven-3.6.2\bin\..
Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
C:\apps\jdk1.8.0_202\jre
Default locale: en_GB, platform encoding: MS932
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

On Mon, Dec 13, 2021 at 7:19 PM Volkan Yazıcı  wrote:

> +1
>
> `./mvnw verify` on `log4j-2.16.0-rc1` branch passes with the following
> setup:
>
> $ java -version
> openjdk version "1.8.0_312"
> OpenJDK Runtime Environment (Zulu 8.58.0.13-CA-linux64) (build
> 1.8.0_312-b07)
> OpenJDK 64-Bit Server VM (Zulu 8.58.0.13-CA-linux64) (build 25.312-b07,
> mixed mode)
>
> $ java -version
> openjdk version "17.0.1" 2021-10-19 LTS
> OpenJDK Runtime Environment Zulu17.30+15-CA (build 17.0.1+12-LTS)
> OpenJDK 64-Bit Server VM Zulu17.30+15-CA (build 17.0.1+12-LTS, mixed mode,
> sharing)
>
> $ uname -a
> Linux tahta 5.11.0-41-generic #45~20.04.1-Ubuntu SMP Wed Nov 10 10:20:10
> UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
>
> Though I would appreciate some small fixes, which can be incorporated later
> on as well:
>
>1. index.md.vm contains references to 2.15.1 and misses Remko's
>improvements in LOG4J2-3214
>
>2. security.md needs to be aligned with LOG4J2-3214
> too
>3. appenders.xml contains references to 2.15.1
>4. lookups.xml contains references to 2.15.1
>5. I want a link to myself in support.md too!
>6. I have encountered multiple occurrences of *"release contains one
>change"* phrase, yet there are actually two changes. I would rather
>rephrase this as *"release contains a limited set of changes focusing on
>security"*.
>7. I have seen that CassandraAppenderIT is disabled due to aarch64
>failures. I would appreciate a ticket for incorporating a
> @DisabledOnArch
>annotation.
>8. In Interpolator.java, there are usages of
>`JndiLookup.class.getName()` and
>`"org.apache.logging.log4j.core.lookup.JndiLookup"`, I'd settle on one.
>9. JNDI changes look good to me, great job Ralph!
>10. I am baffled to see that SimplePerfTest.bubbleSort() was broken, yet
>tests were passing! (Thanks Matt!)
>
> I can actually incorporate website fixes. What is the procedure for that?
> Create a `release-2.16.0` branch derived from `log4j-2.16.0-rc1` tag and
> commit changes there?
>
> On Mon, Dec 13, 2021 at 9:02 AM Ralph Goers 
> wrote:
>
> > +1
> >
> > Verified the signature and the SHA512 hashes. Verified the build worked
> > for me. I did correct some mistakes in the staging site home page news
> > section as it still referenced 2.15.1.
> >
> > Ralph
> >
> >
> > > On Dec 12, 2021, at 11:18 PM, Matt Sicker  wrote:
> > >
> > > This is a vote to release Log4j 2.16.0, the 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 <
> > 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 <
> > 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 <
> > https://logging.staged.apache.org/log4j/2.x/index.html>.
> > >
> > > Maven Artifacts:
> > https://repository.apache.org/content/repositories/orgapachelogging-1068
> <
> > https://repository.apache.org/content/repositories/orgapachelogging-1068
> >
> > >
> > > 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-1068/org/apache/logging/log4j/
> > > --
> > > Matt Sicker
> > >
> >
> >
> >
>

Re: [VOTE] Release Log4j 2.16.0-rc1

+1

`./mvnw verify` on `log4j-2.16.0-rc1` branch passes with the following
setup:

$ java -version
openjdk version "1.8.0_312"
OpenJDK Runtime Environment (Zulu 8.58.0.13-CA-linux64) (build
1.8.0_312-b07)
OpenJDK 64-Bit Server VM (Zulu 8.58.0.13-CA-linux64) (build 25.312-b07,
mixed mode)

$ java -version
openjdk version "17.0.1" 2021-10-19 LTS
OpenJDK Runtime Environment Zulu17.30+15-CA (build 17.0.1+12-LTS)
OpenJDK 64-Bit Server VM Zulu17.30+15-CA (build 17.0.1+12-LTS, mixed mode,
sharing)

$ uname -a
Linux tahta 5.11.0-41-generic #45~20.04.1-Ubuntu SMP Wed Nov 10 10:20:10
UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Though I would appreciate some small fixes, which can be incorporated later
on as well:

   1. index.md.vm contains references to 2.15.1 and misses Remko's
   improvements in LOG4J2-3214
   
   2. security.md needs to be aligned with LOG4J2-3214
    too
   3. appenders.xml contains references to 2.15.1
   4. lookups.xml contains references to 2.15.1
   5. I want a link to myself in support.md too!
   6. I have encountered multiple occurrences of *"release contains one
   change"* phrase, yet there are actually two changes. I would rather
   rephrase this as *"release contains a limited set of changes focusing on
   security"*.
   7. I have seen that CassandraAppenderIT is disabled due to aarch64
   failures. I would appreciate a ticket for incorporating a @DisabledOnArch
   annotation.
   8. In Interpolator.java, there are usages of
   `JndiLookup.class.getName()` and
   `"org.apache.logging.log4j.core.lookup.JndiLookup"`, I'd settle on one.
   9. JNDI changes look good to me, great job Ralph!
   10. I am baffled to see that SimplePerfTest.bubbleSort() was broken, yet
   tests were passing! (Thanks Matt!)

I can actually incorporate website fixes. What is the procedure for that?
Create a `release-2.16.0` branch derived from `log4j-2.16.0-rc1` tag and
commit changes there?

On Mon, Dec 13, 2021 at 9:02 AM Ralph Goers 
wrote:

> +1
>
> Verified the signature and the SHA512 hashes. Verified the build worked
> for me. I did correct some mistakes in the staging site home page news
> section as it still referenced 2.15.1.
>
> Ralph
>
>
> > On Dec 12, 2021, at 11:18 PM, Matt Sicker  wrote:
> >
> > This is a vote to release Log4j 2.16.0, the 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 <
> 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 <
> 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 <
> https://logging.staged.apache.org/log4j/2.x/index.html>.
> >
> > Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachelogging-1068 <
> https://repository.apache.org/content/repositories/orgapachelogging-1068>
> >
> > 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-1068/org/apache/logging/log4j/
> > --
> > Matt Sicker
> >
>
>
>

LOG4J2-3213 CVE missing CPE information in NVD

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

Re: [VOTE] Release Log4j 2.15.1-rc1

I agree with both of your points Remko.

On Mon, Dec 13, 2021 at 2:40 AM Remko Popma  wrote:

> I am also okay with removing Message Lookups from 2.x.
> A release with that change should be called 2.16.0 though, not 2.15.1 or
> 2.15.2.
>
> Also it makes sense to *only* have that security change (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 t

Re: [VOTE] Release Log4j 2.15.1-rc1

Thanks so much for your understanding Ralph, it is very important for me.

For one, message lookups are nothing but a plethora of vulnerabilities. I
think everybody agrees on this. We shouldn't try to make it secure, we
_must_ ditch it off.

Second, I think, again, we shouldn't even be trying to incorporate any
fixes on the JNDI. This approach unfortunately was already proven to be
futile. We should rather have exposed everywhere how dangerous it is and
disabled (actually, preferably, removed) it. The entire internet is buzzing
with JNDI, but I have yet to hear a use case for it. If it would be up to
me, I would even rollback JndiManager checks introduced in 2.15.0. (I am
not suggesting this.) All in all, I guess disabling JNDI by default appears
to be the most sensible next step.

Putting aside all technical details of the next release, we should really
work on the "human" aspect of things. We should come up with a change set
to prove the quality of Log4j and win all broken hearts back. This change
set should shout out loud "we have heard you and thanks for working with
us!" I don't think we are in a hurry with the next release, let's put some
diligent effort into what to ship next.

On Mon, Dec 13, 2021 at 12:12 AM 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:

Re: [VOTE] Release Log4j 2.16.0-rc1