date:20211221

This ticket complains because ConfigurationFactory looks to see if a system 
property named log4j.configuration is set.
 If it is then it tries to initialize the configuration it points to as a Log4j 
1.x configuration using the PropertiesConfiguration I implemented.

Unfortunately, this is the same property name that Log4j 1.x uses. I probably 
thought it was a good thing at the time 
but now that I think about it I believe it was a mistake.

The Log4j 1.x compatibility is still marked experimental. So I would like to 
propose that the property be renamed to log4j1.configurationFile. 
It matches the format used for the Log4j 2 property but is clearly meant to 
reference a Log4j 1.x configuration. This would require users 
who are using the compatibility (if there are any) to change the system 
property name but it would allow log4j 1.x to continue to function 
if it is present in the app.

I do have a concern. Is this going to somehow be renamed as 
log4j2.log4j1.configurationFile by the properties system? That is ugly.

Thoughts?

Ralph

[ANNOUNCE] Apache Log4j 2.12.3 for Java 7 Released

The Apache Log4j 2 team is pleased to announce the Log4j 2.12.3 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, property substitution 
using Lookups, and asynchronous
Loggers. In addition, Log4j 2 will not lose events while reconfiguring.

The major changes contained in this release include:

* Address CVE-2021-45046 and CVE-2021-45105 by disabling recursive evaluation 
of Lookups during log event processing. Recursive evaluation is still allowed 
while generating the configuration.
* Adddress CVE-2021-44882 by preventing JNDI operations to use any protocols 
other than java.
* The JndiLookup, JndiContextSelector, and JMSAppender now require individual 
system properties to be enabled.

The JNDI components are now disabled by default and may separately be enabled 
with three individual properties; log4j2.enableJndiContextSelector, 
log4j2.enableJndiJms, and log4j2.enableJndiLookup.

GA Release 2.12.3

Changes in this version include:

New features:
o LOG4J2-2819:  Add support for specifying an SSL configuration for 
SmtpAppender.

Fixed Bugs:
o LOG4J2-3242: Rename JNDI enablement property from 'log4j2.enableJndi' to 
'log4j2.enableJndiLookup', 'log4j2.enableJndiJms', and  
'log4j2.enableJndiContextSelector'. 
o LOG4J2-3230:  Fix string substitution recursion. 


Apache Log4j 2.12.3 requires a minimum of Java 7 to build and run. It is not 
expected that any future Java 7 releases will be provided.

Basic compatibility with Log4j 1.x is provided through the log4j-1.2-api 
component, however it does not implement some of the
very implementation specific classes and methods. The package names and Maven 
groupId have been changed to
org.apache.logging.log4j to avoid any conflicts with log4j 1.x.

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/log4j-2.12.3/index.html

[ANNOUNCE] Apache Log4j 2.3.1 for Java 6 released

The Apache Log4j 2 team is pleased to announce the Log4j 2.3.1 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, property substitution 
using Lookups, and asynchronous
Loggers. In addition, Log4j 2 will not lose events while reconfiguring.

The major changes contained in this release include:

* Address CVE-2021-45046 and CVE-2021-45105 by disabling recursive evaluation 
of Lookups during log event processing. Recursive evaluation is still allowed 
while generating the configuration.
* Adddress CVE-2021-44882 by removing processing of Lookups in the Message 
Pattern Converter of the Pattern Layout and preventing JNDI operations to use 
any protocols other than java.
* The JndiLookup, JndiContextSelector, and JMSAppender now require individual 
system properties to be enabled.

The JNDI components are now disabled by default and may separately be enabled 
with three individual properties; log4j2.enableJndiContextSelector, 
log4j2.enableJndiJms, and log4j2.enableJndiLookup.

GA Release 2.3.1

Changes in this version include:

New features:
o LOG4J2-3198:  Pattern layout no longer enables lookups within message text. 

Fixed Bugs:
o LOG4J2-3242:  Limit JNDI to the java protocol only. JNDI will remain disabled 
by default. Rename JNDI enablement property from 'log4j2.enableJndi' to 
'log4j2.enableJndiLookup', 'log4j2.enableJndiJms', and 
'log4j2.enableJndiContextSelector'. 
o LOG4J2-3230:  Fix string substitution recursion. 

Apache Log4j 2.3.1 requires a minimum of Java 6 to build and run. It is not 
expected that any future Java 6
releases will be provided.

Basic compatibility with Log4j 1.x is provided through the log4j-1.2-api 
component, however it does not implement some of the
very implementation specific classes and methods. The package names and Maven 
groupId have been changed to
org.apache.logging.log4j to avoid any conflicts with log4j 1.x.

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/log4j-2.3.1/index.html

[RESULT] [VOTE] Release Apache Log4j 2.3.1-rc1

This vote has passed with +1 votes from Ron Grabowski, Gary Gregory, Matt 
Sicker, Carter Kozak, Ralph Goers, and Remko Popma. There were no other votes. 
Tim Perry validated the build on Windows 10 and Java 6.

I will continue with the release process.

Ralph

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

2021-12-21 Thread Tim Perry

I was able to build on Windows 10, with Zulu Java 6.

On Tue, Dec 21, 2021 at 1:29 PM Remko Popma  wrote:

> +1 I am changing my vote.
> My earlier pipecleaning program failed because the config had a JmsAppender
> configured in it... My bad.
> Signatures are good.
> Pipecleaning program works on Java 6 when I remove the JmsAppender from the
> config.
>
> On Wed, Dec 22, 2021 at 6:23 AM Ralph Goers 
> wrote:
>
> > My +1
> >
> > I tested it in an Ubuntu VM and verified it with Java 6.
> >
> > Ralph
> >
> > > On Dec 20, 2021, at 10:18 PM, Ralph Goers 
> > wrote:
> > >
> > > This is a vote to release Log4j 2.3.1, a security release for Java 6
> > users.
> > >
> > > Please download, test, and cast your votes on the log4j developers
> list.
> > > [] +1, release the artifacts
> > > [] -1, don't release because...
> > >
> > > The vote will remain open for as short amount as time as required to
> vet
> > the release. 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:
> > >
> > >
> > > New features:
> > > *  LOG4J2-3198:  Pattern layout no longer enables lookups within
> message
> > text.
> > >
> > > Fixed Bugs:
> > > *  LOG4J2-3242:  Limit JNDI to the java protocol only. JNDI will remain
> > disabled by default. Rename JNDI enablement property from
> > >'log4j2.enableJndi' to 'log4j2.enableJndiLookup',
> > 'log4j2.enableJndiJms', and 'log4j2.enableJndiContextSelector’.
> > > *  LOG4J2-3230:  Fix string substitution recursion.
> > >
> > > Tag:
> > > a)  for a new copy do "git clone
> > https://github.com/apache/logging-log4j2.git; and then "git checkout
> > tags/log4j-2.3.1-rc1”  or just "git clone -b log4j-2.3.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.12.3-rc1”
> > >
> > > Web Site:
> > https://logging.staged.apache.org/log4j/log4j-2.3.1/index.html
> > >
> > > Maven Artifacts:
> > https://repository.apache.org/content/repositories/orgapachelogging-1076
> > >
> > > 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-1076/org/apache/logging/log4j/
> > .
> >
> >
>

[RESULT][VOTE] Release Log4j 2.12.3-rc1

This vote has passed with +1 votes from Matt Sicker, Carter Kozak, Remko Popma, 
Gary Gregory, and Ralph Goers. There were no other votes.

I will continue with the release process.

Ralph

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

+1 I am changing my vote.
My earlier pipecleaning program failed because the config had a JmsAppender
configured in it... My bad.
Signatures are good.
Pipecleaning program works on Java 6 when I remove the JmsAppender from the
config.

On Wed, Dec 22, 2021 at 6:23 AM Ralph Goers 
wrote:

> My +1
>
> I tested it in an Ubuntu VM and verified it with Java 6.
>
> Ralph
>
> > On Dec 20, 2021, at 10:18 PM, Ralph Goers 
> wrote:
> >
> > This is a vote to release Log4j 2.3.1, a security release for Java 6
> users.
> >
> > Please download, test, and cast your votes on the log4j developers list.
> > [] +1, release the artifacts
> > [] -1, don't release because...
> >
> > The vote will remain open for as short amount as time as required to vet
> the release. 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:
> >
> >
> > New features:
> > *  LOG4J2-3198:  Pattern layout no longer enables lookups within message
> text.
> >
> > Fixed Bugs:
> > *  LOG4J2-3242:  Limit JNDI to the java protocol only. JNDI will remain
> disabled by default. Rename JNDI enablement property from
> >'log4j2.enableJndi' to 'log4j2.enableJndiLookup',
> 'log4j2.enableJndiJms', and 'log4j2.enableJndiContextSelector’.
> > *  LOG4J2-3230:  Fix string substitution recursion.
> >
> > Tag:
> > a)  for a new copy do "git clone
> https://github.com/apache/logging-log4j2.git; and then "git checkout
> tags/log4j-2.3.1-rc1”  or just "git clone -b log4j-2.3.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.12.3-rc1”
> >
> > Web Site:
> https://logging.staged.apache.org/log4j/log4j-2.3.1/index.html
> >
> > Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachelogging-1076
> >
> > 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-1076/org/apache/logging/log4j/
> .
>
>

Re: [VOTE] Release Apache Log4j 2.12.3-rc1

My +1

Ralph

> On Dec 20, 2021, at 5:52 PM, Ralph Goers  wrote:
> 
> This is a vote to release Log4j 2.12.3, a security release for Java 7 users.
> 
> Please download, test, and cast your votes on the log4j developers list.
> [] +1, release the artifacts
> [] -1, don't release because...
> 
> The vote will remain open for as short amount as time as required to vet the 
> release. 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
> 
>   • LOG4J2-3230: Fix string substitution recursion.
>   • LOG4J2-3242: Limit JNDI to the java protocol only. JNDI will remain 
> disabled by default. Rename JNDI enablement property from 'log4j2.enableJndi' 
> to 'log4j2.enableJndiLookup', 'log4j2.enableJndiJms', and 
> 'log4j2.enableJndiContextSelector’.
>• LOG4J2-2819: Add support for specifying an SSL configuration for 
> SmtpAppender
> 
> Tag: 
> a)  for a new copy do "git clone 
> https://github.com/apache/logging-log4j2.git; and then "git checkout 
> tags/log4j-2.12.3-rc1”  or just "git clone -b log4j-2.12.3-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.3-rc1”
> 
> Web Site:  https://logging.staged.apache.org/log4j/log4j-2.12.3/index.html
> 
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachelogging-1074
> 
> 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-1074/org/apache/logging/log4j/.

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

My +1

I tested it in an Ubuntu VM and verified it with Java 6.

Ralph

> On Dec 20, 2021, at 10:18 PM, Ralph Goers  wrote:
> 
> This is a vote to release Log4j 2.3.1, a security release for Java 6 users.
> 
> Please download, test, and cast your votes on the log4j developers list.
> [] +1, release the artifacts
> [] -1, don't release because...
> 
> The vote will remain open for as short amount as time as required to vet the 
> release. 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:
> 
> 
> New features:
> *  LOG4J2-3198:  Pattern layout no longer enables lookups within message 
> text. 
> 
> Fixed Bugs:
> *  LOG4J2-3242:  Limit JNDI to the java protocol only. JNDI will remain 
> disabled by default. Rename JNDI enablement property from
>'log4j2.enableJndi' to 'log4j2.enableJndiLookup', 
> 'log4j2.enableJndiJms', and 'log4j2.enableJndiContextSelector’. 
> *  LOG4J2-3230:  Fix string substitution recursion. 
> 
> Tag: 
> a)  for a new copy do "git clone 
> https://github.com/apache/logging-log4j2.git; and then "git checkout 
> tags/log4j-2.3.1-rc1”  or just "git clone -b log4j-2.3.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.12.3-rc1”
> 
> Web Site:  https://logging.staged.apache.org/log4j/log4j-2.3.1/index.html
> 
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachelogging-1076
> 
> 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-1076/org/apache/logging/log4j/.

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

Is it possible that RAT is only configured for reporting and not invocation
from a build? The log4j RAT passes.

Gary



On Tue, Dec 21, 2021, 16:12 Matt Sicker  wrote:

> The jquery.js file has a license header; I have no idea why rat complains
> about it. And these two files are copied verbatim from log4j2, so I don’t
> see the issue here. I looked at the rat report on the site and it looked
> fine, too.
> --
> Matt Sicker
>
> > On Dec 21, 2021, at 14:55, Gary Gregory  wrote:
> >
> > The RAT check (mvn apache-rat:check) fails on:
> >
> >  src/site/resources/js/jquery.min.js
> >  src/site/resources/js/jquery.js
> >
> > If it is indeed ok to ship these files, then the RAT check should exclude
> > these files and the NOTICE file be updated with an appropriate entry. I
> > know this is not the runtime, it's the site, but we still include the
> > files, so might as well be neat and today about it.
> >
> > Also, why ship BOTH the plain and "min" versions?
> >
> > In one of the files, I see "Dual licensed under the MIT or GPL Version 2
> > licenses."
> > I'm pretty sure GPL part is not OK but MIT might be, the comment in the
> RAT
> > exclusion should say so if these are OK to ship.
> >
> > Thoughts?
> >
> > Gary
> >
> > On Mon, Dec 20, 2021 at 11:02 PM Matt Sicker  boa...@gmail.com>> 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 votes and
> more
> >> positive than negative votes are required.
> >>
> >> Changes in this release include:
> >>
> >> * LOG4J2-3218: Update Log4j dependency to 2.17.0.
> >>
> >> This is primarily provided to help upgrade transitive dependencies on
> >> log4j-core which was recently updated to fix CVE-2021-44228,
> >> CVE-2021-45046, and CVE-2021-45105.
> >>
> >> Tag:
> >> a)  for a new copy do "git clone
> >> https://github.com/apache/logging-log4j-kotlin.git <
> >> https://github.com/apache/logging-log4j-kotlin.git <
> https://github.com/apache/logging-log4j-kotlin.git>>” and then "git
> >> checkout tags/log4j-api-kotlin-1.2.0-rc3”  or just "git clone -b
> >> log4j-api-kotlin-1.2.0-rc3
> >> https://github.com/apache/logging-log4j-kotlin.git <
> https://github.com/apache/logging-log4j-kotlin.git> <
> >> https://github.com/apache/logging-log4j-kotlin.git <
> 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-rc3”
> >>
> >> Web Site: https://logging.staged.apache.org/log4j/kotlin/index.html <
> https://logging.staged.apache.org/log4j/kotlin/index.html> <
> >> https://logging.staged.apache.org/log4j/kotlin/index.html <
> https://logging.staged.apache.org/log4j/kotlin/index.html>>
> >>
> >> Maven Artifacts:
> >>
> https://repository.apache.org/content/repositories/orgapachelogging-1075/
>  >
> >>
> >> Distribution archives:
> >> https://dist.apache.org/repos/dist/dev/logging/log4j/kotlin/ <
> https://dist.apache.org/repos/dist/dev/logging/log4j/kotlin/> <
> >> https://dist.apache.org/repos/dist/dev/logging/log4j/kotlin/ <
> 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-1075/org/apache/logging/log4j/
> <
> https://repository.apache.org/content/repositories/orgapachelogging-1075/org/apache/logging/log4j/
> >
> >> <
> >>
> https://repository.apache.org/content/repositories/orgapachelogging-1075/org/apache/logging/log4j/
> <
> https://repository.apache.org/content/repositories/orgapachelogging-1075/org/apache/logging/log4j/
> >
> >>>
> >>
> >> --
> >> Matt Sicker
>
>

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

2021-12-21 Thread Matt Sicker

The jquery.js file has a license header; I have no idea why rat complains about 
it. And these two files are copied verbatim from log4j2, so I don’t see the 
issue here. I looked at the rat report on the site and it looked fine, too.
--
Matt Sicker

> On Dec 21, 2021, at 14:55, Gary Gregory  wrote:
> 
> The RAT check (mvn apache-rat:check) fails on:
> 
>  src/site/resources/js/jquery.min.js
>  src/site/resources/js/jquery.js
> 
> If it is indeed ok to ship these files, then the RAT check should exclude
> these files and the NOTICE file be updated with an appropriate entry. I
> know this is not the runtime, it's the site, but we still include the
> files, so might as well be neat and today about it.
> 
> Also, why ship BOTH the plain and "min" versions?
> 
> In one of the files, I see "Dual licensed under the MIT or GPL Version 2
> licenses."
> I'm pretty sure GPL part is not OK but MIT might be, the comment in the RAT
> exclusion should say so if these are OK to ship.
> 
> Thoughts?
> 
> Gary
> 
> On Mon, Dec 20, 2021 at 11:02 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 votes and more
>> positive than negative votes are required.
>> 
>> Changes in this release include:
>> 
>> * LOG4J2-3218: Update Log4j dependency to 2.17.0.
>> 
>> This is primarily provided to help upgrade transitive dependencies on
>> log4j-core which was recently updated to fix CVE-2021-44228,
>> CVE-2021-45046, and CVE-2021-45105.
>> 
>> Tag:
>> a)  for a new copy do "git clone
>> https://github.com/apache/logging-log4j-kotlin.git <
>> https://github.com/apache/logging-log4j-kotlin.git 
>> >” and then "git
>> checkout tags/log4j-api-kotlin-1.2.0-rc3”  or just "git clone -b
>> log4j-api-kotlin-1.2.0-rc3
>> https://github.com/apache/logging-log4j-kotlin.git 
>>  <
>> 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-rc3”
>> 
>> Web Site: https://logging.staged.apache.org/log4j/kotlin/index.html 
>>  <
>> https://logging.staged.apache.org/log4j/kotlin/index.html 
>> >
>> 
>> Maven Artifacts:
>> https://repository.apache.org/content/repositories/orgapachelogging-1075/ 
>> 
>> 
>> Distribution archives:
>> https://dist.apache.org/repos/dist/dev/logging/log4j/kotlin/ 
>>  <
>> 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-1075/org/apache/logging/log4j/
>>  
>> 
>> <
>> https://repository.apache.org/content/repositories/orgapachelogging-1075/org/apache/logging/log4j/
>>  
>> 
>>> 
>> 
>> --
>> Matt Sicker

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

2021-12-21 Thread Carter Kozak

+1

rat and build succeed, however I don't have a jre6 around to test with.

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 Tue, Dec 21, 2021, at 15:58, Gary Gregory wrote:
> +1
> 
> I did the same steps as Rob but I only used Java 8:
> 
> - mvn apache-rat:check -DskipTests
> - mvn clean install
> - mvn site -DskipTests
> 
> 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.1", arch: "x86_64", family: "mac"
> 
> Darwin *** 21.2.0 Darwin Kernel Version 21.2.0: Sun Nov 28 20:28:54 PST
> 2021; root:xnu-8019.61.5~1/RELEASE_X86_64 x86_64
> 
> Gary
> 
> On Tue, Dec 21, 2021 at 3:51 PM Ron Grabowski
>  wrote:
> 
> > +1
> >
> > I wrote a simple HelloWorld app with 2.3.1 running on jdk1.6.0_45 to
> > further verfiy LOG4J2-3198. These commands ran successfully too:
> >
> > mvn clean install
> > mvn site -DskipTests
> > mvn apache-rat:check -DskipTests
> >
> > 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/21/2021 12:18 AM, Ralph Goers wrote:
> > > This is a vote to release Log4j 2.3.1, a security release for Java 6
> > users.
> > >
> > > Please download, test, and cast your votes on the log4j developers list.
> > > [] +1, release the artifacts
> > > [] -1, don't release because...
> > >
> > > The vote will remain open for as short amount as time as required to vet
> > the release. 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:
> > >
> > >
> > > New features:
> > > *  LOG4J2-3198:  Pattern layout no longer enables lookups within message
> > text.
> > >
> > > Fixed Bugs:
> > > *  LOG4J2-3242:  Limit JNDI to the java protocol only. JNDI will remain
> > disabled by default. Rename JNDI enablement property from
> > >  'log4j2.enableJndi' to 'log4j2.enableJndiLookup',
> > 'log4j2.enableJndiJms', and 'log4j2.enableJndiContextSelector’.
> > > *  LOG4J2-3230:  Fix string substitution recursion.
> > >
> > > Tag:
> > > a)  for a new copy do "git clone
> > https://github.com/apache/logging-log4j2.git; and then "git checkout
> > tags/log4j-2.3.1-rc1”  or just "git clone -b log4j-2.3.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.12.3-rc1”
> > >
> > > Web Site:
> > https://logging.staged.apache.org/log4j/log4j-2.3.1/index.html
> > >
> > > Maven Artifacts:
> > https://repository.apache.org/content/repositories/orgapachelogging-1076
> > >
> > > 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-1076/org/apache/logging/log4j/
> > .
> >
>

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

2021-12-21 Thread Matt Sicker

+1

Signatures good, build good, artifacts good.
--
Matt Sicker

> On Dec 20, 2021, at 23:18, Ralph Goers  wrote:
> 
> This is a vote to release Log4j 2.3.1, a security release for Java 6 users.
> 
> Please download, test, and cast your votes on the log4j developers list.
> [] +1, release the artifacts
> [] -1, don't release because...
> 
> The vote will remain open for as short amount as time as required to vet the 
> release. 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:
> 
> 
> New features:
> *  LOG4J2-3198:  Pattern layout no longer enables lookups within message 
> text. 
> 
> Fixed Bugs:
> *  LOG4J2-3242:  Limit JNDI to the java protocol only. JNDI will remain 
> disabled by default. Rename JNDI enablement property from
>'log4j2.enableJndi' to 'log4j2.enableJndiLookup', 
> 'log4j2.enableJndiJms', and 'log4j2.enableJndiContextSelector’. 
> *  LOG4J2-3230:  Fix string substitution recursion. 
> 
> Tag: 
> a)  for a new copy do "git clone 
> https://github.com/apache/logging-log4j2.git; and then "git checkout 
> tags/log4j-2.3.1-rc1”  or just "git clone -b log4j-2.3.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.12.3-rc1”
> 
> Web Site:  https://logging.staged.apache.org/log4j/log4j-2.3.1/index.html
> 
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachelogging-1076
> 
> 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-1076/org/apache/logging/log4j/.

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

+1

I did the same steps as Rob but I only used Java 8:

- mvn apache-rat:check -DskipTests
- mvn clean install
- mvn site -DskipTests

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.1", arch: "x86_64", family: "mac"

Darwin *** 21.2.0 Darwin Kernel Version 21.2.0: Sun Nov 28 20:28:54 PST
2021; root:xnu-8019.61.5~1/RELEASE_X86_64 x86_64

Gary

On Tue, Dec 21, 2021 at 3:51 PM Ron Grabowski
 wrote:

> +1
>
> I wrote a simple HelloWorld app with 2.3.1 running on jdk1.6.0_45 to
> further verfiy LOG4J2-3198. These commands ran successfully too:
>
> mvn clean install
> mvn site -DskipTests
> mvn apache-rat:check -DskipTests
>
> 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/21/2021 12:18 AM, Ralph Goers wrote:
> > This is a vote to release Log4j 2.3.1, a security release for Java 6
> users.
> >
> > Please download, test, and cast your votes on the log4j developers list.
> > [] +1, release the artifacts
> > [] -1, don't release because...
> >
> > The vote will remain open for as short amount as time as required to vet
> the release. 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:
> >
> >
> > New features:
> > *  LOG4J2-3198:  Pattern layout no longer enables lookups within message
> text.
> >
> > Fixed Bugs:
> > *  LOG4J2-3242:  Limit JNDI to the java protocol only. JNDI will remain
> disabled by default. Rename JNDI enablement property from
> >  'log4j2.enableJndi' to 'log4j2.enableJndiLookup',
> 'log4j2.enableJndiJms', and 'log4j2.enableJndiContextSelector’.
> > *  LOG4J2-3230:  Fix string substitution recursion.
> >
> > Tag:
> > a)  for a new copy do "git clone
> https://github.com/apache/logging-log4j2.git; and then "git checkout
> tags/log4j-2.3.1-rc1”  or just "git clone -b log4j-2.3.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.12.3-rc1”
> >
> > Web Site:
> https://logging.staged.apache.org/log4j/log4j-2.3.1/index.html
> >
> > Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachelogging-1076
> >
> > 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-1076/org/apache/logging/log4j/
> .
>

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

The RAT check (mvn apache-rat:check) fails on:

  src/site/resources/js/jquery.min.js
  src/site/resources/js/jquery.js

If it is indeed ok to ship these files, then the RAT check should exclude
these files and the NOTICE file be updated with an appropriate entry. I
know this is not the runtime, it's the site, but we still include the
files, so might as well be neat and today about it.

Also, why ship BOTH the plain and "min" versions?

In one of the files, I see "Dual licensed under the MIT or GPL Version 2
licenses."
I'm pretty sure GPL part is not OK but MIT might be, the comment in the RAT
exclusion should say so if these are OK to ship.

Thoughts?

Gary

On Mon, Dec 20, 2021 at 11:02 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 votes and more
> positive than negative votes are required.
>
> Changes in this release include:
>
> * LOG4J2-3218: Update Log4j dependency to 2.17.0.
>
> This is primarily provided to help upgrade transitive dependencies on
> log4j-core which was recently updated to fix CVE-2021-44228,
> CVE-2021-45046, and CVE-2021-45105.
>
> Tag:
> a)  for a new copy do "git clone
> https://github.com/apache/logging-log4j-kotlin.git <
> https://github.com/apache/logging-log4j-kotlin.git>” and then "git
> checkout tags/log4j-api-kotlin-1.2.0-rc3”  or just "git clone -b
> log4j-api-kotlin-1.2.0-rc3
> https://github.com/apache/logging-log4j-kotlin.git <
> 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-rc3”
>
> Web Site: https://logging.staged.apache.org/log4j/kotlin/index.html <
> https://logging.staged.apache.org/log4j/kotlin/index.html>
>
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachelogging-1075/
>
> Distribution archives:
> https://dist.apache.org/repos/dist/dev/logging/log4j/kotlin/ <
> 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-1075/org/apache/logging/log4j/
> <
> https://repository.apache.org/content/repositories/orgapachelogging-1075/org/apache/logging/log4j/
> >
>
>  --
> Matt Sicker
>
>

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

2021-12-21 Thread Ron Grabowski

I wrote a simple HelloWorld app with 2.3.1 running on jdk1.6.0_45 to
further verfiy LOG4J2-3198. These commands ran successfully too:

mvn clean install
mvn site -DskipTests
mvn apache-rat:check -DskipTests

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/21/2021 12:18 AM, Ralph Goers wrote:

This is a vote to release Log4j 2.3.1, a security release for Java 6 users.

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

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

New features:
* LOG4J2-3198: Pattern layout no longer enables lookups within message text.

Fixed Bugs:
* LOG4J2-3242: Limit JNDI to the java protocol only. JNDI will remain
disabled by default. Rename JNDI enablement property from
'log4j2.enableJndi' to 'log4j2.enableJndiLookup',
'log4j2.enableJndiJms', and 'log4j2.enableJndiContextSelector’.
* LOG4J2-3230: Fix string substitution recursion.

Tag:
a) for a new copy do "git clone https://github.com/apache/logging-log4j2.git; and then
"git checkout tags/log4j-2.3.1-rc1” or just "git clone -b log4j-2.3.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.12.3-rc1”

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

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

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

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

I will report on the build I started before I left the house, but I won't
be back for an hour or two.

Gary

On Tue, Dec 21, 2021, 13:29 Ralph Goers  wrote:

> I have installed Java 6 in an Ubuntu VM and created a simple all that just
> logs Hello, world!.  I had no problem running it in Java 6 with the 2.3.1
> api and core jars.
>
> Remko, if you want to do a screen share I’d be happy to demo it.
>
> Ralph
>
> > On Dec 21, 2021, at 7:15 AM, Ralph Goers 
> wrote:
> >
> > You should try 2.3. I bet you get the same result. I bet we enhanced the
> plugin system to ignore plugins that get NoClassDefFoundError.
> >
> > Ralph
> >
> >> On Dec 21, 2021, at 6:41 AM, Remko Popma  wrote:
> >>
> >> Gary,
> >>
> >> No it’s literally that pipe cleaning class, the api and core jar, and a
> Log4j2.xml with just the console Appender.
> >>
> >> That should work though without any extra dependencies.
> >>
> >> Interestingly the same setup does work without errors with 2.12.3 on
> Java 7.
> >>
> >> What’s the difference between 2.3.1 and 2.12.3?
> >>
> >> Remko
> >>
> >>
> >>> On Dec 21, 2021, at 22:37, Gary Gregory 
> wrote:
> >>>
> >>> Remko:
> >>>
> >>> JMS is not built-in the JRE, do you have JMS in your configuration for
> >>> this test? If you do, then you'd need the JMS API and a provider as
> >>> dependencies.
> >>>
> >>> Gary
> >>>
>  On Tue, Dec 21, 2021 at 7:37 AM Ralph Goers <
> ralph.go...@dslextreme.com> wrote:
> 
>  Hmmm. This is not what I was expecting. If it didn’t work I would
> have expected bad class version exceptions.
> 
>  Ralph
> 
> >> On Dec 21, 2021, at 4:28 AM, Remko Popma 
> wrote:
> >
> > -1 it does not work...
> >
> > Problem running a simple pipecleaning test on Java 6 with 2.3.1...
> > My pipecleaning program is something simple like this
> >
> > public class Pipecleaning {
> > public static void main(String[] args) {
> > org.apache.logging.log4j.LogManager.getLogger().info("HELLO
> > USER ${sys:user.name}");
> >
> > I only have 2 jars in the classpath, log4j-api-2.3.1 and
> log4j-core-2.3.1.The
> > problem is that Log4j configuration fails...
> >
> > Exception in thread "main" java.lang.NoClassDefFoundError:
> > javax/jms/JMSException
> > at java.lang.Class.getDeclaredMethods0(Native Method)
> > at java.lang.Class.privateGetDeclaredMethods(Class.java:2436)
> > at java.lang.Class.getDeclaredMethods(Class.java:1793)
> > at
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.createBuilder(PluginBuilder.java:154)
> > at
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:120)
> > at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:781)
> >
> >
> >> On Tue, Dec 21, 2021 at 2:18 PM Ralph Goers <
> ralph.go...@dslextreme.com>
> >> wrote:
> >>
> >> This is a vote to release Log4j 2.3.1, a security release for Java
> 6 users.
> >>
> >> Please download, test, and cast your votes on the log4j developers
> list.
> >> [] +1, release the artifacts
> >> [] -1, don't release because...
> >>
> >> The vote will remain open for as short amount as time as required
> to vet
> >> the release. 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:
> >>
> >>
> >> New features:
> >> *  LOG4J2-3198:  Pattern layout no longer enables lookups within
> message
> >> text.
> >>
> >> Fixed Bugs:
> >> *  LOG4J2-3242:  Limit JNDI to the java protocol only. JNDI will
> remain
> >> disabled by default. Rename JNDI enablement property from
> >> 'log4j2.enableJndi' to 'log4j2.enableJndiLookup',
> >> 'log4j2.enableJndiJms', and 'log4j2.enableJndiContextSelector’.
> >> *  LOG4J2-3230:  Fix string substitution recursion.
> >>
> >> Tag:
> >> a)  for a new copy do "git clone
> >> https://github.com/apache/logging-log4j2.git; and then "git
> checkout
> >> tags/log4j-2.3.1-rc1”  or just "git clone -b log4j-2.3.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.12.3-rc1”
> >>
> >> Web Site:
> https://logging.staged.apache.org/log4j/log4j-2.3.1/index.html
> >>
> >> Maven Artifacts:
> >>
> https://repository.apache.org/content/repositories/orgapachelogging-1076
> >>
> >> 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
> >>
>

Re: Resurrecting log4j 1.x

Note that this “requires access to the logging configuration” is simply wrong. 
I wish I had 
known 10 years ago what I now know about JNDI, and Java’s LDAP support via 
JNDI. 
Unfortunately, I only learned about it in the last 3 weeks.

The LDAP schema for Java is where the real problem lies. It defines data to 
instantiate 
classes that implement the Referenceable interface. These classes are created 
via an 
ObjectFactory. The wonderful thing about the Java schema. Is that it defines 
referenece 
address attributes, which is the location of where you can find the object 
factory class object.

So if have access to LDAP you can manipulate the data to point to your own 
ObjectFactory. 
So long as that returns whatever the caller was expecting you can do whatever 
else you 
want completely undetected. Or if you have access to wherever the objects 
reside you can 
replace them there with a custom class.

Of course, Java also supports Serializable objects via LDAP and everyone knows 
that has 
holes like Swiss cheese.

So if you have an existing configuration that already accesses LDAP via JNDI to 
get a 
password no one needs to touch the config file to perform an RCE.  

This is the perfect way for an unhappy employee to create a backdoor.

Ralph

> On Dec 21, 2021, at 11:12 AM, Leo Simons  wrote:
> 
> On Tue, 21 Dec 2021 at 18:48, Gary Gregory  wrote:
> 
>> …
>> I wonder what logback actually means by "Temporarily removed DB support for
>> security reasons.", did they remove public or protected code? Well we have
>> enough to deal with here without worrying about that.
> 
> 
> Yeah they deleted DBAppender. Public code that you can/should reference in
> a config file. So source/binary/config incompatible.
> 
> https://github.com/qos-ch/logback/commit/87291079a1de9369ac67e20dc70a8fdc7cc4359c
> 
> So logback 1.2.8 has it, 1.2.9 doesn’t, 1.3 (JDK8+) will probably get a
> security hardened version, probably then backported to make a 1.2.10 for
> JDK7.
> 
> (Of course a very different project, different vulnerability, etc, so
> different considerations & choices)
> 
> Spring is picking it up in their release:
> 
> https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot
> 
> So Twitter after Christmas will start to teach us about user response :-)
> 
> 
> Cheers,
> 
> 
> Leo

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

I have installed Java 6 in an Ubuntu VM and created a simple all that just logs 
Hello, world!.  I had no problem running it in Java 6 with the 2.3.1 api and 
core jars.

Remko, if you want to do a screen share I’d be happy to demo it.

Ralph

> On Dec 21, 2021, at 7:15 AM, Ralph Goers  wrote:
> 
> You should try 2.3. I bet you get the same result. I bet we enhanced the 
> plugin system to ignore plugins that get NoClassDefFoundError.
> 
> Ralph
> 
>> On Dec 21, 2021, at 6:41 AM, Remko Popma  wrote:
>> 
>> Gary,
>> 
>> No it’s literally that pipe cleaning class, the api and core jar, and a 
>> Log4j2.xml with just the console Appender. 
>> 
>> That should work though without any extra dependencies. 
>> 
>> Interestingly the same setup does work without errors with 2.12.3 on Java 7. 
>> 
>> What’s the difference between 2.3.1 and 2.12.3?
>> 
>> Remko
>> 
>> 
>>> On Dec 21, 2021, at 22:37, Gary Gregory  wrote:
>>> 
>>> Remko:
>>> 
>>> JMS is not built-in the JRE, do you have JMS in your configuration for
>>> this test? If you do, then you'd need the JMS API and a provider as
>>> dependencies.
>>> 
>>> Gary
>>> 
 On Tue, Dec 21, 2021 at 7:37 AM Ralph Goers  
 wrote:
 
 Hmmm. This is not what I was expecting. If it didn’t work I would have 
 expected bad class version exceptions.
 
 Ralph
 
>> On Dec 21, 2021, at 4:28 AM, Remko Popma  wrote:
> 
> -1 it does not work...
> 
> Problem running a simple pipecleaning test on Java 6 with 2.3.1...
> My pipecleaning program is something simple like this
> 
> public class Pipecleaning {
> public static void main(String[] args) {
> org.apache.logging.log4j.LogManager.getLogger().info("HELLO
> USER ${sys:user.name}");
> 
> I only have 2 jars in the classpath, log4j-api-2.3.1 and 
> log4j-core-2.3.1.The
> problem is that Log4j configuration fails...
> 
> Exception in thread "main" java.lang.NoClassDefFoundError:
> javax/jms/JMSException
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2436)
> at java.lang.Class.getDeclaredMethods(Class.java:1793)
> at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.createBuilder(PluginBuilder.java:154)
> at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:120)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:781)
> 
> 
>> On Tue, Dec 21, 2021 at 2:18 PM Ralph Goers 
>> wrote:
>> 
>> This is a vote to release Log4j 2.3.1, a security release for Java 6 
>> users.
>> 
>> Please download, test, and cast your votes on the log4j developers list.
>> [] +1, release the artifacts
>> [] -1, don't release because...
>> 
>> The vote will remain open for as short amount as time as required to vet
>> the release. 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:
>> 
>> 
>> New features:
>> *  LOG4J2-3198:  Pattern layout no longer enables lookups within message
>> text.
>> 
>> Fixed Bugs:
>> *  LOG4J2-3242:  Limit JNDI to the java protocol only. JNDI will remain
>> disabled by default. Rename JNDI enablement property from
>> 'log4j2.enableJndi' to 'log4j2.enableJndiLookup',
>> 'log4j2.enableJndiJms', and 'log4j2.enableJndiContextSelector’.
>> *  LOG4J2-3230:  Fix string substitution recursion.
>> 
>> Tag:
>> a)  for a new copy do "git clone
>> https://github.com/apache/logging-log4j2.git; and then "git checkout
>> tags/log4j-2.3.1-rc1”  or just "git clone -b log4j-2.3.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.12.3-rc1”
>> 
>> Web Site:  https://logging.staged.apache.org/log4j/log4j-2.3.1/index.html
>> 
>> Maven Artifacts:
>> https://repository.apache.org/content/repositories/orgapachelogging-1076
>> 
>> 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-1076/org/apache/logging/log4j/
>> .
 
 
>> 
> 
>

Re: Resurrecting log4j 1.x

2021-12-21 Thread Leo Simons

On Tue, 21 Dec 2021 at 18:48, Gary Gregory  wrote:

> …
> I wonder what logback actually means by "Temporarily removed DB support for
> security reasons.", did they remove public or protected code? Well we have
> enough to deal with here without worrying about that.

Yeah they deleted DBAppender. Public code that you can/should reference in
a config file. So source/binary/config incompatible.

https://github.com/qos-ch/logback/commit/87291079a1de9369ac67e20dc70a8fdc7cc4359c

So logback 1.2.8 has it, 1.2.9 doesn’t, 1.3 (JDK8+) will probably get a
security hardened version, probably then backported to make a 1.2.10 for
JDK7.

(Of course a very different project, different vulnerability, etc, so
different considerations & choices)

Spring is picking it up in their release:

https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot

So Twitter after Christmas will start to teach us about user response :-)

Cheers,

Leo

Re: Resurrecting log4j 1.x

WRT naming, let's stay with considering a 1.2.18, that's the type of naming
we used in 2.x with 2.12.x and 2.3.x, no need to make things more
complicated IMO.

I wonder what logback actually means by "Temporarily removed DB support for
security reasons.", did they remove public or protected code? Well we have
enough to deal with here without worrying about that.

Gary

On Tue, Dec 21, 2021, 12:05 Leo Simons  wrote:

> (On mobile, excuse typos/top post)
>
> +1. My interest is in staying here, work together, make a security release
> as one community (and I probably will be gone when security is no longer a
> topic), that is as good as possible, out soon(tm). I won’t object to but
> also won’t join something “new” (feel free to use any code I wrote of
> course).
>
> PMC is supportive but busy with 2.x. Focus on 2.x is right. Cool there is a
> 2.3 patch coming. Learn anything relevant to 1.x? When 2.x security worries
> die down, there is time for 1.x security worries (after seasonal holidays
> too, I hope!). All this was said. Asking for some patience is
> understandable. As contributors we can prepare the code in parallel, maybe
> host an RC somewhere to get testing done, write security/migration docs. I
> ran out of time, not out of work that could progress.
>
> I think involving incubator is wrong. Subproject process at incubator is
> for IP clearance which is not needed here. Starting a new TLP for log4j 1
> is confusing, lot of work, not needed. Let’s work together here. (I was on
> incubator PMC many years, started and retired couple projects too.)
>
> Grateful for critical review and attention from committers. Feedback should
> be considered. For example did you know Gary worked on 1.x way back when,
> and has also maintained a bunch of other ex-Jakarta stuff for years and
> years? (like 20?) Meritocracy means his word has weight, but more important
> - experience means his feedback is worth gold.
>
> How to balance quality of solution with timeliness? Logback dropped
> DB support temporarily (
> https://logback.qos.ch/news.html ). Difficult judgements to make. Don’t
> have to agree on all details. Ultimately “code talks”, make something
> “obviously” better than 1.2 and we will have agreement enough. Take some
> time to explore the friction to find the best outcome we can. (Deleting
> log4j.net and making a JDK 11 release can be done by everyone on GitHub,
> I’m convinced the Apache community can contribute something better, curious
> how much better.)
>
> Having the conversations is how we find the best approach. Back in
> 2004/2005 I worked on gump as a way to keep backward compatibility in core
> libraries like ant,xerces,log4j, it has been educational for me to argue
> the other direction now for once…I am normally not the “move faster” guy…
> and it’s even for the same bloody code… :-).
>
> With (an evolution of) the second PR I started, naming wise we could go for
> “1.2.17.1”, making the “security only” part extra clear.
>
>
> Cheers!
>
>
> Leo
>
> On Tue, 21 Dec 2021 at 15:18, Ralph Goers 
> wrote:
>
> > To be clear, we have declared Java 6 & 7 EOL for Log4j 2. Yet we are here
> > building
> > patch releases for them. We are only including the security patches. I
> see
> > Log4j 1.x
> > as exactly the same as those.
> >
> > Ralph
> >
> > > On Dec 21, 2021, at 6:45 AM, Gary Gregory 
> > wrote:
> > >
> > > I agree with Remko on all his points.
> > >
> > > As I've stated before, IF there is a 1.2.18, it should ONLY be for
> CVEs,
> > > and where applicable, fixed in the same style as we have for 2.x. This
> > is,
> > > IMO, what would be best for users *short* of migrating for 2.x.
> > >
> > > A problem from my perspective will be users thinking the project is
> > > resurrected and asking for "just this little fix" or "just that little
> > > feature", which would be a "no" from me.
> > >
> > > We have a 1.2 compatibility layer in 2.x, let's make that better so
> that
> > > 2.x could become as close as possible to a drop-in replacement for 1.2.
> > >
> > > Gary
> > >
> > >
> > > On Tue, Dec 21, 2021 at 8:36 AM Remko Popma 
> > wrote:
> > >
> > >> Vladimir,
> > >>
> > >> Have you had a chance to work on a patch for the security
> > vulnerabilities?
> > >>
> > >> While there is understandably not much interest in “resurrecting” the
> > >> Log4j 1.x project, overall people are positive about releasing a
> 1.2.18
> > >> with security patches.
> > >>
> > >> I think it would be most helpful if we can stay focused on those
> > security
> > >> patches rather than pushing the PMC for an effort to revive an EOL
> > project.
> > >>
> > >> I can see how things appear to be moving very slowly from your
> > >> perspective, but as Ralph pointed out the PMC is pretty busy with 2.x
> > patch
> > >> releases and the flood of email that has been piling up.
> > >>
> > >> I see your enthusiasm and eagerness to contribute and that’s really
> > great!
> > >> I would suggest that you direct that energy towards looking

Re: Resurrecting log4j 1.x

2021-12-21 Thread Leo Simons

(On mobile, excuse typos/top post)

+1. My interest is in staying here, work together, make a security release
as one community (and I probably will be gone when security is no longer a
topic), that is as good as possible, out soon(tm). I won’t object to but
also won’t join something “new” (feel free to use any code I wrote of
course).

PMC is supportive but busy with 2.x. Focus on 2.x is right. Cool there is a
2.3 patch coming. Learn anything relevant to 1.x? When 2.x security worries
die down, there is time for 1.x security worries (after seasonal holidays
too, I hope!). All this was said. Asking for some patience is
understandable. As contributors we can prepare the code in parallel, maybe
host an RC somewhere to get testing done, write security/migration docs. I
ran out of time, not out of work that could progress.

I think involving incubator is wrong. Subproject process at incubator is
for IP clearance which is not needed here. Starting a new TLP for log4j 1
is confusing, lot of work, not needed. Let’s work together here. (I was on
incubator PMC many years, started and retired couple projects too.)

Grateful for critical review and attention from committers. Feedback should
be considered. For example did you know Gary worked on 1.x way back when,
and has also maintained a bunch of other ex-Jakarta stuff for years and
years? (like 20?) Meritocracy means his word has weight, but more important
- experience means his feedback is worth gold.

How to balance quality of solution with timeliness? Logback dropped
DB support temporarily (
https://logback.qos.ch/news.html ). Difficult judgements to make. Don’t
have to agree on all details. Ultimately “code talks”, make something
“obviously” better than 1.2 and we will have agreement enough. Take some
time to explore the friction to find the best outcome we can. (Deleting
log4j.net and making a JDK 11 release can be done by everyone on GitHub,
I’m convinced the Apache community can contribute something better, curious
how much better.)

Having the conversations is how we find the best approach. Back in
2004/2005 I worked on gump as a way to keep backward compatibility in core
libraries like ant,xerces,log4j, it has been educational for me to argue
the other direction now for once…I am normally not the “move faster” guy…
and it’s even for the same bloody code… :-).

With (an evolution of) the second PR I started, naming wise we could go for
“1.2.17.1”, making the “security only” part extra clear.

Cheers!

Leo

On Tue, 21 Dec 2021 at 15:18, Ralph Goers 
wrote:

> To be clear, we have declared Java 6 & 7 EOL for Log4j 2. Yet we are here
> building
> patch releases for them. We are only including the security patches. I see
> Log4j 1.x
> as exactly the same as those.
>
> Ralph
>
> > On Dec 21, 2021, at 6:45 AM, Gary Gregory 
> wrote:
> >
> > I agree with Remko on all his points.
> >
> > As I've stated before, IF there is a 1.2.18, it should ONLY be for CVEs,
> > and where applicable, fixed in the same style as we have for 2.x. This
> is,
> > IMO, what would be best for users *short* of migrating for 2.x.
> >
> > A problem from my perspective will be users thinking the project is
> > resurrected and asking for "just this little fix" or "just that little
> > feature", which would be a "no" from me.
> >
> > We have a 1.2 compatibility layer in 2.x, let's make that better so that
> > 2.x could become as close as possible to a drop-in replacement for 1.2.
> >
> > Gary
> >
> >
> > On Tue, Dec 21, 2021 at 8:36 AM Remko Popma 
> wrote:
> >
> >> Vladimir,
> >>
> >> Have you had a chance to work on a patch for the security
> vulnerabilities?
> >>
> >> While there is understandably not much interest in “resurrecting” the
> >> Log4j 1.x project, overall people are positive about releasing a 1.2.18
> >> with security patches.
> >>
> >> I think it would be most helpful if we can stay focused on those
> security
> >> patches rather than pushing the PMC for an effort to revive an EOL
> project.
> >>
> >> I can see how things appear to be moving very slowly from your
> >> perspective, but as Ralph pointed out the PMC is pretty busy with 2.x
> patch
> >> releases and the flood of email that has been piling up.
> >>
> >> I see your enthusiasm and eagerness to contribute and that’s really
> great!
> >> I would suggest that you direct that energy towards looking at the Log4j
> >> 1.x source code, figuring out what classes should be modified in which
> way,
> >> and how to test those changes.
> >> And discussing such code changes on the mailing list together with
> fellow
> >> enthusiasts.
> >>
> >> Migration to git will happen. Maybe not as fast as you would like, but
> >> please cut the PMC some slack in this stressful time.
> >>
> >> Surely you can start working on the actual security improvements without
> >> re-incubating a Log4j 1.x project, in parallel with (while waiting for)
> the
> >> migration from svn to git?
> >>
> >> Onwards,
> >>
> >> Remko
> >>
> >>
> >>> On Dec 21,

Re: Resurrecting log4j 1.x

To be clear, we have declared Java 6 & 7 EOL for Log4j 2. Yet we are here 
building 
patch releases for them. We are only including the security patches. I see 
Log4j 1.x 
as exactly the same as those.

Ralph

> On Dec 21, 2021, at 6:45 AM, Gary Gregory  wrote:
> 
> I agree with Remko on all his points.
> 
> As I've stated before, IF there is a 1.2.18, it should ONLY be for CVEs,
> and where applicable, fixed in the same style as we have for 2.x. This is,
> IMO, what would be best for users *short* of migrating for 2.x.
> 
> A problem from my perspective will be users thinking the project is
> resurrected and asking for "just this little fix" or "just that little
> feature", which would be a "no" from me.
> 
> We have a 1.2 compatibility layer in 2.x, let's make that better so that
> 2.x could become as close as possible to a drop-in replacement for 1.2.
> 
> Gary
> 
> 
> On Tue, Dec 21, 2021 at 8:36 AM Remko Popma  wrote:
> 
>> Vladimir,
>> 
>> Have you had a chance to work on a patch for the security vulnerabilities?
>> 
>> While there is understandably not much interest in “resurrecting” the
>> Log4j 1.x project, overall people are positive about releasing a 1.2.18
>> with security patches.
>> 
>> I think it would be most helpful if we can stay focused on those security
>> patches rather than pushing the PMC for an effort to revive an EOL project.
>> 
>> I can see how things appear to be moving very slowly from your
>> perspective, but as Ralph pointed out the PMC is pretty busy with 2.x patch
>> releases and the flood of email that has been piling up.
>> 
>> I see your enthusiasm and eagerness to contribute and that’s really great!
>> I would suggest that you direct that energy towards looking at the Log4j
>> 1.x source code, figuring out what classes should be modified in which way,
>> and how to test those changes.
>> And discussing such code changes on the mailing list together with fellow
>> enthusiasts.
>> 
>> Migration to git will happen. Maybe not as fast as you would like, but
>> please cut the PMC some slack in this stressful time.
>> 
>> Surely you can start working on the actual security improvements without
>> re-incubating a Log4j 1.x project, in parallel with (while waiting for) the
>> migration from svn to git?
>> 
>> Onwards,
>> 
>> Remko
>> 
>> 
>>> On Dec 21, 2021, at 20:52, Vladimir Sitnikov <
>> sitnikov.vladi...@gmail.com> wrote:
>>> 
>>> Ron,
>>> 
>>> I know these are not easy times for you,
>>> however, it looks like we are going in circles.
>>> 
>>> There's visible demand for releasing fixes for 1.x:
>>> https://lists.apache.org/thread/llgp7b9v1t081o3215o7xq4zpct1x0b4
>>> 
>>> So the question is
>>> "Could you sponsor the project or do you want Incubator to do that?"
>>> 
>>> I see the current crew is not interested in fixing and releasing 1.x.
>>> Why don't you just allow others to fix things?
>>> 
>>> Vladimir
>>

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

You should try 2.3. I bet you get the same result. I bet we enhanced the plugin 
system to ignore plugins that get NoClassDefFoundError.

Ralph

> On Dec 21, 2021, at 6:41 AM, Remko Popma  wrote:
> 
> Gary,
> 
> No it’s literally that pipe cleaning class, the api and core jar, and a 
> Log4j2.xml with just the console Appender. 
> 
> That should work though without any extra dependencies. 
> 
> Interestingly the same setup does work without errors with 2.12.3 on Java 7. 
> 
> What’s the difference between 2.3.1 and 2.12.3?
> 
> Remko
> 
> 
>> On Dec 21, 2021, at 22:37, Gary Gregory  wrote:
>> 
>> Remko:
>> 
>> JMS is not built-in the JRE, do you have JMS in your configuration for
>> this test? If you do, then you'd need the JMS API and a provider as
>> dependencies.
>> 
>> Gary
>> 
>>> On Tue, Dec 21, 2021 at 7:37 AM Ralph Goers  
>>> wrote:
>>> 
>>> Hmmm. This is not what I was expecting. If it didn’t work I would have 
>>> expected bad class version exceptions.
>>> 
>>> Ralph
>>> 
> On Dec 21, 2021, at 4:28 AM, Remko Popma  wrote:
 
 -1 it does not work...
 
 Problem running a simple pipecleaning test on Java 6 with 2.3.1...
 My pipecleaning program is something simple like this
 
 public class Pipecleaning {
  public static void main(String[] args) {
  org.apache.logging.log4j.LogManager.getLogger().info("HELLO
 USER ${sys:user.name}");
 
 I only have 2 jars in the classpath, log4j-api-2.3.1 and 
 log4j-core-2.3.1.The
 problem is that Log4j configuration fails...
 
 Exception in thread "main" java.lang.NoClassDefFoundError:
 javax/jms/JMSException
  at java.lang.Class.getDeclaredMethods0(Native Method)
  at java.lang.Class.privateGetDeclaredMethods(Class.java:2436)
  at java.lang.Class.getDeclaredMethods(Class.java:1793)
  at 
 org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.createBuilder(PluginBuilder.java:154)
  at 
 org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:120)
  at 
 org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:781)
 
 
> On Tue, Dec 21, 2021 at 2:18 PM Ralph Goers 
> wrote:
> 
> This is a vote to release Log4j 2.3.1, a security release for Java 6 
> users.
> 
> Please download, test, and cast your votes on the log4j developers list.
> [] +1, release the artifacts
> [] -1, don't release because...
> 
> The vote will remain open for as short amount as time as required to vet
> the release. 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:
> 
> 
> New features:
> *  LOG4J2-3198:  Pattern layout no longer enables lookups within message
> text.
> 
> Fixed Bugs:
> *  LOG4J2-3242:  Limit JNDI to the java protocol only. JNDI will remain
> disabled by default. Rename JNDI enablement property from
>  'log4j2.enableJndi' to 'log4j2.enableJndiLookup',
> 'log4j2.enableJndiJms', and 'log4j2.enableJndiContextSelector’.
> *  LOG4J2-3230:  Fix string substitution recursion.
> 
> Tag:
> a)  for a new copy do "git clone
> https://github.com/apache/logging-log4j2.git; and then "git checkout
> tags/log4j-2.3.1-rc1”  or just "git clone -b log4j-2.3.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.12.3-rc1”
> 
> Web Site:  https://logging.staged.apache.org/log4j/log4j-2.3.1/index.html
> 
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachelogging-1076
> 
> 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-1076/org/apache/logging/log4j/
> .
>>> 
>>> 
>

Re: Resurrecting log4j 1.x

I agree with Remko on all his points.

As I've stated before, IF there is a 1.2.18, it should ONLY be for CVEs,
and where applicable, fixed in the same style as we have for 2.x. This is,
IMO, what would be best for users *short* of migrating for 2.x.

A problem from my perspective will be users thinking the project is
resurrected and asking for "just this little fix" or "just that little
feature", which would be a "no" from me.

We have a 1.2 compatibility layer in 2.x, let's make that better so that
2.x could become as close as possible to a drop-in replacement for 1.2.

Gary


On Tue, Dec 21, 2021 at 8:36 AM Remko Popma  wrote:

> Vladimir,
>
> Have you had a chance to work on a patch for the security vulnerabilities?
>
> While there is understandably not much interest in “resurrecting” the
> Log4j 1.x project, overall people are positive about releasing a 1.2.18
> with security patches.
>
> I think it would be most helpful if we can stay focused on those security
> patches rather than pushing the PMC for an effort to revive an EOL project.
>
> I can see how things appear to be moving very slowly from your
> perspective, but as Ralph pointed out the PMC is pretty busy with 2.x patch
> releases and the flood of email that has been piling up.
>
> I see your enthusiasm and eagerness to contribute and that’s really great!
> I would suggest that you direct that energy towards looking at the Log4j
> 1.x source code, figuring out what classes should be modified in which way,
> and how to test those changes.
> And discussing such code changes on the mailing list together with fellow
> enthusiasts.
>
> Migration to git will happen. Maybe not as fast as you would like, but
> please cut the PMC some slack in this stressful time.
>
> Surely you can start working on the actual security improvements without
> re-incubating a Log4j 1.x project, in parallel with (while waiting for) the
> migration from svn to git?
>
> Onwards,
>
> Remko
>
>
> > On Dec 21, 2021, at 20:52, Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote:
> >
> > Ron,
> >
> > I know these are not easy times for you,
> > however, it looks like we are going in circles.
> >
> > There's visible demand for releasing fixes for 1.x:
> > https://lists.apache.org/thread/llgp7b9v1t081o3215o7xq4zpct1x0b4
> >
> > So the question is
> > "Could you sponsor the project or do you want Incubator to do that?"
> >
> > I see the current crew is not interested in fixing and releasing 1.x.
> > Why don't you just allow others to fix things?
> >
> > Vladimir
>

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

Gary,

No it’s literally that pipe cleaning class, the api and core jar, and a 
Log4j2.xml with just the console Appender. 

That should work though without any extra dependencies. 

Interestingly the same setup does work without errors with 2.12.3 on Java 7. 

What’s the difference between 2.3.1 and 2.12.3?

Remko

> On Dec 21, 2021, at 22:37, Gary Gregory  wrote:
> 
> Remko:
> 
> JMS is not built-in the JRE, do you have JMS in your configuration for
> this test? If you do, then you'd need the JMS API and a provider as
> dependencies.
> 
> Gary
> 
>> On Tue, Dec 21, 2021 at 7:37 AM Ralph Goers  
>> wrote:
>> 
>> Hmmm. This is not what I was expecting. If it didn’t work I would have 
>> expected bad class version exceptions.
>> 
>> Ralph
>> 
 On Dec 21, 2021, at 4:28 AM, Remko Popma  wrote:
>>> 
>>> -1 it does not work...
>>> 
>>> Problem running a simple pipecleaning test on Java 6 with 2.3.1...
>>> My pipecleaning program is something simple like this
>>> 
>>> public class Pipecleaning {
>>>   public static void main(String[] args) {
>>>   org.apache.logging.log4j.LogManager.getLogger().info("HELLO
>>> USER ${sys:user.name}");
>>> 
>>> I only have 2 jars in the classpath, log4j-api-2.3.1 and 
>>> log4j-core-2.3.1.The
>>> problem is that Log4j configuration fails...
>>> 
>>> Exception in thread "main" java.lang.NoClassDefFoundError:
>>> javax/jms/JMSException
>>>   at java.lang.Class.getDeclaredMethods0(Native Method)
>>>   at java.lang.Class.privateGetDeclaredMethods(Class.java:2436)
>>>   at java.lang.Class.getDeclaredMethods(Class.java:1793)
>>>   at 
>>> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.createBuilder(PluginBuilder.java:154)
>>>   at 
>>> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:120)
>>>   at 
>>> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:781)
>>> 
>>> 
 On Tue, Dec 21, 2021 at 2:18 PM Ralph Goers 
 wrote:

 This is a vote to release Log4j 2.3.1, a security release for Java 6 users.

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

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

 New features:
 *  LOG4J2-3198:  Pattern layout no longer enables lookups within message
 text.

 Fixed Bugs:
 *  LOG4J2-3242:  Limit JNDI to the java protocol only. JNDI will remain
 disabled by default. Rename JNDI enablement property from
   'log4j2.enableJndi' to 'log4j2.enableJndiLookup',
 'log4j2.enableJndiJms', and 'log4j2.enableJndiContextSelector’.
 *  LOG4J2-3230:  Fix string substitution recursion.

 Tag:
 a)  for a new copy do "git clone
 https://github.com/apache/logging-log4j2.git; and then "git checkout
 tags/log4j-2.3.1-rc1”  or just "git clone -b log4j-2.3.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.12.3-rc1”

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

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

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

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

Remko:

JMS is not built-in the JRE, do you have JMS in your configuration for
this test? If you do, then you'd need the JMS API and a provider as
dependencies.

Gary

On Tue, Dec 21, 2021 at 7:37 AM Ralph Goers  wrote:
>
> Hmmm. This is not what I was expecting. If it didn’t work I would have 
> expected bad class version exceptions.
>
> Ralph
>
> > On Dec 21, 2021, at 4:28 AM, Remko Popma  wrote:
> >
> > -1 it does not work...
> >
> > Problem running a simple pipecleaning test on Java 6 with 2.3.1...
> > My pipecleaning program is something simple like this
> >
> > public class Pipecleaning {
> >public static void main(String[] args) {
> >org.apache.logging.log4j.LogManager.getLogger().info("HELLO
> > USER ${sys:user.name}");
> >
> > I only have 2 jars in the classpath, log4j-api-2.3.1 and 
> > log4j-core-2.3.1.The
> > problem is that Log4j configuration fails...
> >
> > Exception in thread "main" java.lang.NoClassDefFoundError:
> > javax/jms/JMSException
> >at java.lang.Class.getDeclaredMethods0(Native Method)
> >at java.lang.Class.privateGetDeclaredMethods(Class.java:2436)
> >at java.lang.Class.getDeclaredMethods(Class.java:1793)
> >at 
> > org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.createBuilder(PluginBuilder.java:154)
> >at 
> > org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:120)
> >at 
> > org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:781)
> >
> >
> >> On Tue, Dec 21, 2021 at 2:18 PM Ralph Goers 
> >> wrote:
> >>
> >> This is a vote to release Log4j 2.3.1, a security release for Java 6 users.
> >>
> >> Please download, test, and cast your votes on the log4j developers list.
> >> [] +1, release the artifacts
> >> [] -1, don't release because...
> >>
> >> The vote will remain open for as short amount as time as required to vet
> >> the release. 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:
> >>
> >>
> >> New features:
> >> *  LOG4J2-3198:  Pattern layout no longer enables lookups within message
> >> text.
> >>
> >> Fixed Bugs:
> >> *  LOG4J2-3242:  Limit JNDI to the java protocol only. JNDI will remain
> >> disabled by default. Rename JNDI enablement property from
> >>'log4j2.enableJndi' to 'log4j2.enableJndiLookup',
> >> 'log4j2.enableJndiJms', and 'log4j2.enableJndiContextSelector’.
> >> *  LOG4J2-3230:  Fix string substitution recursion.
> >>
> >> Tag:
> >> a)  for a new copy do "git clone
> >> https://github.com/apache/logging-log4j2.git; and then "git checkout
> >> tags/log4j-2.3.1-rc1”  or just "git clone -b log4j-2.3.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.12.3-rc1”
> >>
> >> Web Site:  https://logging.staged.apache.org/log4j/log4j-2.3.1/index.html
> >>
> >> Maven Artifacts:
> >> https://repository.apache.org/content/repositories/orgapachelogging-1076
> >>
> >> 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-1076/org/apache/logging/log4j/
> >> .
>
>

Re: Resurrecting log4j 1.x

Vladimir,

Have you had a chance to work on a patch for the security vulnerabilities?

While there is understandably not much interest in “resurrecting” the Log4j 1.x 
project, overall people are positive about releasing a 1.2.18 with security 
patches. 

I think it would be most helpful if we can stay focused on those security 
patches rather than pushing the PMC for an effort to revive an EOL project. 

I can see how things appear to be moving very slowly from your perspective, but 
as Ralph pointed out the PMC is pretty busy with 2.x patch releases and the 
flood of email that has been piling up. 

I see your enthusiasm and eagerness to contribute and that’s really great! I 
would suggest that you direct that energy towards looking at the Log4j 1.x 
source code, figuring out what classes should be modified in which way, and how 
to test those changes. 
And discussing such code changes on the mailing list together with fellow 
enthusiasts. 

Migration to git will happen. Maybe not as fast as you would like, but please 
cut the PMC some slack in this stressful time. 

Surely you can start working on the actual security improvements without 
re-incubating a Log4j 1.x project, in parallel with (while waiting for) the 
migration from svn to git? 

Onwards,

Remko

> On Dec 21, 2021, at 20:52, Vladimir Sitnikov  
> wrote:
> 
> Ron,
> 
> I know these are not easy times for you,
> however, it looks like we are going in circles.
> 
> There's visible demand for releasing fixes for 1.x:
> https://lists.apache.org/thread/llgp7b9v1t081o3215o7xq4zpct1x0b4
> 
> So the question is
> "Could you sponsor the project or do you want Incubator to do that?"
> 
> I see the current crew is not interested in fixing and releasing 1.x.
> Why don't you just allow others to fix things?
> 
> Vladimir

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

Hmmm. This is not what I was expecting. If it didn’t work I would have expected 
bad class version exceptions.

Ralph

> On Dec 21, 2021, at 4:28 AM, Remko Popma  wrote:
> 
> -1 it does not work...
> 
> Problem running a simple pipecleaning test on Java 6 with 2.3.1...
> My pipecleaning program is something simple like this
> 
> public class Pipecleaning {
>public static void main(String[] args) {
>org.apache.logging.log4j.LogManager.getLogger().info("HELLO
> USER ${sys:user.name}");
> 
> I only have 2 jars in the classpath, log4j-api-2.3.1 and log4j-core-2.3.1.The
> problem is that Log4j configuration fails...
> 
> Exception in thread "main" java.lang.NoClassDefFoundError:
> javax/jms/JMSException
>at java.lang.Class.getDeclaredMethods0(Native Method)
>at java.lang.Class.privateGetDeclaredMethods(Class.java:2436)
>at java.lang.Class.getDeclaredMethods(Class.java:1793)
>at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.createBuilder(PluginBuilder.java:154)
>at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:120)
>at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:781)
> 
> 
>> On Tue, Dec 21, 2021 at 2:18 PM Ralph Goers 
>> wrote:
>> 
>> This is a vote to release Log4j 2.3.1, a security release for Java 6 users.
>> 
>> Please download, test, and cast your votes on the log4j developers list.
>> [] +1, release the artifacts
>> [] -1, don't release because...
>> 
>> The vote will remain open for as short amount as time as required to vet
>> the release. 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:
>> 
>> 
>> New features:
>> *  LOG4J2-3198:  Pattern layout no longer enables lookups within message
>> text.
>> 
>> Fixed Bugs:
>> *  LOG4J2-3242:  Limit JNDI to the java protocol only. JNDI will remain
>> disabled by default. Rename JNDI enablement property from
>>'log4j2.enableJndi' to 'log4j2.enableJndiLookup',
>> 'log4j2.enableJndiJms', and 'log4j2.enableJndiContextSelector’.
>> *  LOG4J2-3230:  Fix string substitution recursion.
>> 
>> Tag:
>> a)  for a new copy do "git clone
>> https://github.com/apache/logging-log4j2.git; and then "git checkout
>> tags/log4j-2.3.1-rc1”  or just "git clone -b log4j-2.3.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.12.3-rc1”
>> 
>> Web Site:  https://logging.staged.apache.org/log4j/log4j-2.3.1/index.html
>> 
>> Maven Artifacts:
>> https://repository.apache.org/content/repositories/orgapachelogging-1076
>> 
>> 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-1076/org/apache/logging/log4j/
>> .

Re: [VOTE] Release Apache Log4j 2.12.3-rc1

+1 then

Gary

On Mon, Dec 20, 2021 at 10:50 PM Ralph Goers  wrote:
>
> There was a bug in the site build. I checked the fix in to the branch. It 
> doesn’t matter for the release.
>
> Ralph
>
> > On Dec 20, 2021, at 6:46 PM, Gary Gregory  wrote:
> >
> > Building from the git tag for HEAD detached at log4j-2.12.3-rc1 (2b9359b23)
> >
> > - mvn apache-rat:check -DskipTests OK
> > - mvn clean install OK except a JVM crash I always get in the
> > Cassandra module tests, just like always.
> > - mvn site -DskipTests fails with:
> >
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on
> > project log4j: Error parsing
> > '/Users/garydgregory/git/logging-log4j-2.12/src/site/xdoc/manual/appenders.xml':
> > line [1713] Error parsing the model: end tag name  must
> > match start tag name  from line 1533 (position: TEXT seen
> > ...\n\n... @1713:22)  -> [Help 1]
> >
> > Is that just me?
> >
> > Built with:
> >
> > 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.1", arch: "x86_64", family: "mac"
> >
> > Darwin *** 21.2.0 Darwin Kernel Version 21.2.0: Sun Nov 28 20:28:54
> > PST 2021; root:xnu-8019.61.5~1/RELEASE_X86_64 x86_64
> >
> > Gary
> >
> > On Mon, Dec 20, 2021 at 7:52 PM Ralph Goers  
> > wrote:
> >>
> >> This is a vote to release Log4j 2.12.3, a security release for Java 7 
> >> users.
> >>
> >> Please download, test, and cast your votes on the log4j developers list.
> >> [] +1, release the artifacts
> >> [] -1, don't release because...
> >>
> >> The vote will remain open for as short amount as time as required to vet 
> >> the release. 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
> >>
> >>• LOG4J2-3230: Fix string substitution recursion.
> >>• LOG4J2-3242: Limit JNDI to the java protocol only. JNDI will 
> >> remain disabled by default. Rename JNDI enablement property from 
> >> 'log4j2.enableJndi' to 'log4j2.enableJndiLookup', 'log4j2.enableJndiJms', 
> >> and 'log4j2.enableJndiContextSelector’.
> >>• LOG4J2-2819: Add support for specifying an SSL configuration for 
> >> SmtpAppender
> >>
> >> Tag:
> >> a)  for a new copy do "git clone 
> >> https://github.com/apache/logging-log4j2.git; and then "git checkout 
> >> tags/log4j-2.12.3-rc1”  or just "git clone -b log4j-2.12.3-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.3-rc1”
> >>
> >> Web Site:  https://logging.staged.apache.org/log4j/log4j-2.12.3/index.html
> >>
> >> Maven Artifacts: 
> >> https://repository.apache.org/content/repositories/orgapachelogging-1074
> >>
> >> 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-1074/org/apache/logging/log4j/.
> >
>

Re: Resurrecting log4j 1.x

2021-12-21 Thread Vladimir Sitnikov

Ron,

I know these are not easy times for you,
however, it looks like we are going in circles.

There's visible demand for releasing fixes for 1.x:
https://lists.apache.org/thread/llgp7b9v1t081o3215o7xq4zpct1x0b4

So the question is
"Could you sponsor the project or do you want Incubator to do that?"

I see the current crew is not interested in fixing and releasing 1.x.
Why don't you just allow others to fix things?

Vladimir

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