Re: [VOTE] Release Apache Log4j 2.12.3-rc1

2021-12-20 Thread Remko Popma
+1
Remko

On Tue, Dec 21, 2021 at 12:52 PM Carter Kozak  wrote:

> +1
>
> -ck
>
> > On Dec 20, 2021, at 22:46, Matt Sicker  wrote:
> >
> > +1
> >
> > Notes on the release:
> > * Sigs and checksums good
> > * Builds and tests fine
> > * Outdated copyright year in NOTICE.txt
> >
> > --
> > Matt Sicker
> >
> >> On Dec 20, 2021, at 18:52, 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: [logging-log4j2] 01/01: [DOC] Fix log4j-2.3.x About page incorrect security.html anchor links

2021-12-20 Thread Remko Popma
Thank you Gary! Great catch!

On Tue, Dec 21, 2021 at 11:51 AM Gary Gregory 
wrote:

> I'm not sure this is the right branch, I think log4j-2.3.x is the
> right one.
>
> Ralph?
>
> Gary
>
> On Mon, Dec 20, 2021, 21:33  wrote:
>
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > rpopma pushed a commit to branch java6
> > in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
> >
> > commit 6e298ba0df07451beced3ed4de2ec71cfdf6b734
> > Author: rpopma 
> > AuthorDate: Tue Dec 21 11:33:44 2021 +0900
> >
> > [DOC] Fix log4j-2.3.x About page incorrect security.html anchor links
> > ---
> >  src/site/xdoc/index.xml | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/site/xdoc/index.xml b/src/site/xdoc/index.xml
> > index b3e8f3f..d289bf7 100644
> > --- a/src/site/xdoc/index.xml
> > +++ b/src/site/xdoc/index.xml
> > @@ -68,7 +68,7 @@
> >Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or
> > 2.17.0 (for Java 8).
> >
> >Reference
> > -  Please refer to the https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45105
> ">Security
> > page for details and mitigation measures for older versions of
> > Log4j.
> > +  Please refer to the https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45046
> ">Security
> > page for details and mitigation measures for older versions of
> > Log4j.
> >
> >
> >
> > @@ -89,7 +89,7 @@
> >Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or
> > 2.17.0 (for Java 8).
> >
> >Reference
> > -  Please refer to the https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45105
> ">Security
> > page for details and mitigation measures for older versions of
> > Log4j.
> > +  Please refer to the https://logging.apache.org/log4j/2.x/security.html#CVE-2021-44228
> ">Security
> > page for details and mitigation measures for older versions of
> > Log4j.
> >
> >
> >
> >
>


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

2021-12-20 Thread Ralph Goers
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/.

[VOTE] Release Log4j Kotlin API 1.2.0-rc3

2021-12-20 Thread Matt Sicker
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 
” 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 
"
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 


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

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


 --
Matt Sicker



Re: [VOTE] Release Apache Log4j 2.12.3-rc1

2021-12-20 Thread Carter Kozak
+1

-ck

> On Dec 20, 2021, at 22:46, Matt Sicker  wrote:
> 
> +1
> 
> Notes on the release:
> * Sigs and checksums good
> * Builds and tests fine
> * Outdated copyright year in NOTICE.txt
> 
> --
> Matt Sicker
> 
>> On Dec 20, 2021, at 18:52, 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.12.3-rc1

2021-12-20 Thread Ralph Goers
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: [VOTE] Release Apache Log4j 2.12.3-rc1

2021-12-20 Thread Matt Sicker
+1

Notes on the release:
* Sigs and checksums good
* Builds and tests fine
* Outdated copyright year in NOTICE.txt

--
Matt Sicker

> On Dec 20, 2021, at 18:52, 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 Log4j Kotlin API 1.2.0-rc2

2021-12-20 Thread Matt Sicker
I fixed some rat errors, but yeah, looks like I missed that. I’ll cancel this 
and roll a third RC.

—
Matt Sicker

> On Dec 20, 2021, at 20:43, Raman Gupta  wrote:
> 
> As far as I can tell nothing has changed? Did you mean to point to 2.17.0?
> 
>> On Sun, Dec 19, 2021 at 5:52 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 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:
>> 
>> * 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 and
>> CVE-2021-45046.
>> 
>> 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-rc2”  or just "git clone -b
>> log4j-api-kotlin-1.2.0-rc2
>> 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-rc2”
>> 
>> Web Site: https://logging.staged.apache.org/log4j/kotlin/index.html
>> 
>> Maven Artifacts:
>> https://repository.apache.org/content/repositories/orgapachelogging-1073/
>> 
>> 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-1073/org/apache/logging/log4j/
>> 
>> --
>> Matt Sicker
>> 
>> 


Re: [logging-log4j2] 01/01: [DOC] Fix log4j-2.3.x About page incorrect security.html anchor links

2021-12-20 Thread Gary Gregory
I'm not sure this is the right branch, I think log4j-2.3.x is the
right one.

Ralph?

Gary

On Mon, Dec 20, 2021, 21:33  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> rpopma pushed a commit to branch java6
> in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
>
> commit 6e298ba0df07451beced3ed4de2ec71cfdf6b734
> Author: rpopma 
> AuthorDate: Tue Dec 21 11:33:44 2021 +0900
>
> [DOC] Fix log4j-2.3.x About page incorrect security.html anchor links
> ---
>  src/site/xdoc/index.xml | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/site/xdoc/index.xml b/src/site/xdoc/index.xml
> index b3e8f3f..d289bf7 100644
> --- a/src/site/xdoc/index.xml
> +++ b/src/site/xdoc/index.xml
> @@ -68,7 +68,7 @@
>Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or
> 2.17.0 (for Java 8).
>
>Reference
> -  Please refer to the https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45105";>Security
> page for details and mitigation measures for older versions of
> Log4j.
> +  Please refer to the https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45046";>Security
> page for details and mitigation measures for older versions of
> Log4j.
>
>
>
> @@ -89,7 +89,7 @@
>Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or
> 2.17.0 (for Java 8).
>
>Reference
> -  Please refer to the https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45105";>Security
> page for details and mitigation measures for older versions of
> Log4j.
> +  Please refer to the https://logging.apache.org/log4j/2.x/security.html#CVE-2021-44228";>Security
> page for details and mitigation measures for older versions of
> Log4j.
>
>
>
>


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

2021-12-20 Thread Raman Gupta
As far as I can tell nothing has changed? Did you mean to point to 2.17.0?

On Sun, Dec 19, 2021 at 5:52 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 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:
>
> * 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 and
> CVE-2021-45046.
>
> 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-rc2”  or just "git clone -b
> log4j-api-kotlin-1.2.0-rc2
> 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-rc2”
>
> Web Site: https://logging.staged.apache.org/log4j/kotlin/index.html
>
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachelogging-1073/
>
> 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-1073/org/apache/logging/log4j/
>
>  --
> Matt Sicker
>
>


Broken CI

2021-12-20 Thread Gary Gregory
After getting https://github.com/apache/logging-log4j2/pull/646 in what I
think is a good state, I have no idea if it is safe or not to merge because
the 1st build GitHub shows is red:
https://github.com/apache/logging-log4j2/runs/4589771553?check_suite_focus=true

I don't use GH actions the way we do here and I'm not sure why we need the
publish test result set when anyone can just look at the build logs.

Gary


Re: [VOTE] Release Apache Log4j 2.12.3-rc1

2021-12-20 Thread Gary Gregory
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/.


[VOTE] Release Apache Log4j 2.12.3-rc1

2021-12-20 Thread Ralph Goers
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: Couldn't build release branch without reverting the 2.17.1-SNAPSHOT naming commit

2021-12-20 Thread Matt Sicker
You need to run "mvn install" to get the build to work properly
locally. This is due to some overlapping Maven hackery to bundle Java
9+ code back into the Java 8 code.

On Mon, Dec 20, 2021 at 4:00 PM Dan Kegel  wrote:
>
> I guess this is expected, but on my 2nd machine, I couldn't build the
> release branch because it couldn't find 2.17.1-SNAPSHOT stuff:
>
> [ERROR] Failed to execute goal on project log4j-1.2-api: Could not
> resolve dependencies for project
> org.apache.logging.log4j:log4j-1.2-api:jar:2.17.1-SNAPSHOT:
> org.apache.logging.log4j:log4j-core:jar:tests:2.17.1-SNAPSHOT was not
> found in https://repository.apache.org/snapshots during a previous
> attempt.
>
> After I locally reverted
> https://github.com/apache/logging-log4j2/commit/461dbf25944317de2e689bf6ab2eeb932f143bd4,
> it built ok.
>
> *shrug*
> - Dan


Couldn't build release branch without reverting the 2.17.1-SNAPSHOT naming commit

2021-12-20 Thread Dan Kegel
I guess this is expected, but on my 2nd machine, I couldn't build the
release branch because it couldn't find 2.17.1-SNAPSHOT stuff:

[ERROR] Failed to execute goal on project log4j-1.2-api: Could not
resolve dependencies for project
org.apache.logging.log4j:log4j-1.2-api:jar:2.17.1-SNAPSHOT:
org.apache.logging.log4j:log4j-core:jar:tests:2.17.1-SNAPSHOT was not
found in https://repository.apache.org/snapshots during a previous
attempt.

After I locally reverted
https://github.com/apache/logging-log4j2/commit/461dbf25944317de2e689bf6ab2eeb932f143bd4,
it built ok.

*shrug*
- Dan


Re: Configuration element for system properties

2021-12-20 Thread Ralph Goers
It is not a typo. We may be missing documentation. I’ll have to search and see.

Ralph

> On Dec 20, 2021, at 1:18 PM, Gary Gregory  wrote:
> 
> Our page 
> https://logging.apache.org/log4j/2.x/manual/configuration.html#SystemProperties
> documents log4j2.component.properties, but you talk about
> log4j2.system.properties. Is that a typo or are we missing
> documentation?
> 
> Gary
> 
> On Mon, Dec 20, 2021 at 3:12 PM Ralph Goers  
> wrote:
>> 
>> This proposal is problematic. By the time this happens it is possible it is 
>> too late for some system properties to do any good.
>> 
>> I implemented support for system properties already. I had a need for it for 
>> the Spring support. Just put the properties in log4j2.system.properties.
>> 
>> PropertiesUtil populates the SystemProperties when it creates the 
>> Environment.
>> 
>> Ralph
>> 
>>> On Dec 20, 2021, at 12:18 PM, Gary Gregory  wrote:
>>> 
>>> Hello,
>>> 
>>> I'd like to propose that we add an element called SystemProperty to
>>> our configuration. This would look like our current Property element
>>> but would set a system property instead of a configuration property.
>>> 
>>> My use case is, at work, our tooling generates one XML configuration
>>> file for a user's project and additional XML files for each DTAP
>>> environment. The main Log4j configuration file uses XInclude to bring
>>> in the appropriate DTAP file. Depending on the configuration of the
>>> user's project, and in light of Log4j's use of system properties,
>>> specifically, our new enableJndi* system properties, it would be nice
>>> to be able to say in DTAP XML files something like >> key="enableJndiJms>true or whatever Property
>>> supports.
>>> 
>>> Thoughts?
>>> 
>>> Gary
>>> 
>> 
> 



Re: Configuration element for system properties

2021-12-20 Thread Gary Gregory
Our page 
https://logging.apache.org/log4j/2.x/manual/configuration.html#SystemProperties
documents log4j2.component.properties, but you talk about
log4j2.system.properties. Is that a typo or are we missing
documentation?

Gary

On Mon, Dec 20, 2021 at 3:12 PM Ralph Goers  wrote:
>
> This proposal is problematic. By the time this happens it is possible it is 
> too late for some system properties to do any good.
>
> I implemented support for system properties already. I had a need for it for 
> the Spring support. Just put the properties in log4j2.system.properties.
>
> PropertiesUtil populates the SystemProperties when it creates the Environment.
>
> Ralph
>
> > On Dec 20, 2021, at 12:18 PM, Gary Gregory  wrote:
> >
> > Hello,
> >
> > I'd like to propose that we add an element called SystemProperty to
> > our configuration. This would look like our current Property element
> > but would set a system property instead of a configuration property.
> >
> > My use case is, at work, our tooling generates one XML configuration
> > file for a user's project and additional XML files for each DTAP
> > environment. The main Log4j configuration file uses XInclude to bring
> > in the appropriate DTAP file. Depending on the configuration of the
> > user's project, and in light of Log4j's use of system properties,
> > specifically, our new enableJndi* system properties, it would be nice
> > to be able to say in DTAP XML files something like  > key="enableJndiJms>true or whatever Property
> > supports.
> >
> > Thoughts?
> >
> > Gary
> >
>


Re: Configuration element for system properties

2021-12-20 Thread Ralph Goers
This proposal is problematic. By the time this happens it is possible it is too 
late for some system properties to do any good. 

I implemented support for system properties already. I had a need for it for 
the Spring support. Just put the properties in log4j2.system.properties.

PropertiesUtil populates the SystemProperties when it creates the Environment.

Ralph

> On Dec 20, 2021, at 12:18 PM, Gary Gregory  wrote:
> 
> Hello,
> 
> I'd like to propose that we add an element called SystemProperty to
> our configuration. This would look like our current Property element
> but would set a system property instead of a configuration property.
> 
> My use case is, at work, our tooling generates one XML configuration
> file for a user's project and additional XML files for each DTAP
> environment. The main Log4j configuration file uses XInclude to bring
> in the appropriate DTAP file. Depending on the configuration of the
> user's project, and in light of Log4j's use of system properties,
> specifically, our new enableJndi* system properties, it would be nice
> to be able to say in DTAP XML files something like  key="enableJndiJms>true or whatever Property
> supports.
> 
> Thoughts?
> 
> Gary
> 



Re: Resurrecting log4j 1.x

2021-12-20 Thread Gary Gregory
Is https://github.com/apache/log4j a mirror of an SVN repo?

Gary

On Mon, Dec 20, 2021 at 2:31 PM Carter Kozak  wrote:
>
> Same, git migration makes sense to me if we are fixing CVEs.
>
> -ck
>
> > On Dec 20, 2021, at 14:28, Matt Sicker  wrote:
> >
> > Sorry, I forgot to vote explicitly. I'd be +1 on the git repo
> > migration, but I was also iffy on enabling issues there.
> >
> >> On Mon, Dec 20, 2021 at 1:23 PM Vladimir Sitnikov
> >>  wrote:
> >>
> >> Ralph>I have no problem doing stuff on GitHub
> >>
> >> Bingo!
> >> That is what I said earlier.
> >>
> >> It is really really demotivating that "PMC is not against".
> >> I suggested the move. Neither Ralph nor Matt welcomed the change with +1.
> >>
> >> At no time do I request you to perform the Git migration.
> >> At no time do I request you to refactor the build scripts.
> >> Yet you do ask A LOT before you even try doing something.
> >>
> >> That is exactly the reason I believe it is way less time consuming for all
> >> the parties to re-incubate 1.x
> >> rather than keep all those "But someone needs to migrate".
> >>
> >> Ralph>But someone needs to migrate it from SVN and I don’t have the time
> >> for that
> >>
> >> I can do that just fine. Would you just approve the move?
> >> Is it really that hard to respond with +1 on move to Git thread?
> >> What I get is -1(binding), and irrelevant comments like "someone needs to
> >> migrate".
> >> Thank you. I know someone needs to do that.
> >>
> >> The Git repository with the full log4j 1.x history already exists.
> >> I highlighted it on a "[VOTE] Move log4j 1.x from SVN to Git" thread:
> >> https://lists.apache.org/thread/0z34x9536mtr2z98m4s4dpqglzvjhjfq
> >>
> >> Vladimir
>


Re: Configuration element for system properties

2021-12-20 Thread Gary Gregory
This one; log4j2.component.properties.

That's good indeed, as of now, our tooling is not something I can
easily update to generate a new file that then gets propagated to the
right place. But it is "simple" to add another entry to an existing
file. Not something Log4j needs to worry about of course.

Gary

On Mon, Dec 20, 2021 at 2:24 PM Matt Sicker  wrote:
>
> Without additional refactoring, the only way this would work is if the
> logging config is the only config in the application. System
> properties are global to the JVM. There's already a properties file
> you can include that gets loaded as a log4j2 system properties file,
> by the way.
>
> On Mon, Dec 20, 2021 at 1:19 PM Gary Gregory  wrote:
> >
> > Hello,
> >
> > I'd like to propose that we add an element called SystemProperty to
> > our configuration. This would look like our current Property element
> > but would set a system property instead of a configuration property.
> >
> > My use case is, at work, our tooling generates one XML configuration
> > file for a user's project and additional XML files for each DTAP
> > environment. The main Log4j configuration file uses XInclude to bring
> > in the appropriate DTAP file. Depending on the configuration of the
> > user's project, and in light of Log4j's use of system properties,
> > specifically, our new enableJndi* system properties, it would be nice
> > to be able to say in DTAP XML files something like  > key="enableJndiJms>true or whatever Property
> > supports.
> >
> > Thoughts?
> >
> > Gary


Re: Resurrecting log4j 1.x

2021-12-20 Thread Carter Kozak
Same, git migration makes sense to me if we are fixing CVEs.

-ck

> On Dec 20, 2021, at 14:28, Matt Sicker  wrote:
> 
> Sorry, I forgot to vote explicitly. I'd be +1 on the git repo
> migration, but I was also iffy on enabling issues there.
> 
>> On Mon, Dec 20, 2021 at 1:23 PM Vladimir Sitnikov
>>  wrote:
>> 
>> Ralph>I have no problem doing stuff on GitHub
>> 
>> Bingo!
>> That is what I said earlier.
>> 
>> It is really really demotivating that "PMC is not against".
>> I suggested the move. Neither Ralph nor Matt welcomed the change with +1.
>> 
>> At no time do I request you to perform the Git migration.
>> At no time do I request you to refactor the build scripts.
>> Yet you do ask A LOT before you even try doing something.
>> 
>> That is exactly the reason I believe it is way less time consuming for all
>> the parties to re-incubate 1.x
>> rather than keep all those "But someone needs to migrate".
>> 
>> Ralph>But someone needs to migrate it from SVN and I don’t have the time
>> for that
>> 
>> I can do that just fine. Would you just approve the move?
>> Is it really that hard to respond with +1 on move to Git thread?
>> What I get is -1(binding), and irrelevant comments like "someone needs to
>> migrate".
>> Thank you. I know someone needs to do that.
>> 
>> The Git repository with the full log4j 1.x history already exists.
>> I highlighted it on a "[VOTE] Move log4j 1.x from SVN to Git" thread:
>> https://lists.apache.org/thread/0z34x9536mtr2z98m4s4dpqglzvjhjfq
>> 
>> Vladimir



Re: Resurrecting log4j 1.x

2021-12-20 Thread Matt Sicker
Sorry, I forgot to vote explicitly. I'd be +1 on the git repo
migration, but I was also iffy on enabling issues there.

On Mon, Dec 20, 2021 at 1:23 PM Vladimir Sitnikov
 wrote:
>
> Ralph>I have no problem doing stuff on GitHub
>
> Bingo!
> That is what I said earlier.
>
> It is really really demotivating that "PMC is not against".
> I suggested the move. Neither Ralph nor Matt welcomed the change with +1.
>
> At no time do I request you to perform the Git migration.
> At no time do I request you to refactor the build scripts.
> Yet you do ask A LOT before you even try doing something.
>
> That is exactly the reason I believe it is way less time consuming for all
> the parties to re-incubate 1.x
> rather than keep all those "But someone needs to migrate".
>
> Ralph>But someone needs to migrate it from SVN and I don’t have the time
> for that
>
> I can do that just fine. Would you just approve the move?
> Is it really that hard to respond with +1 on move to Git thread?
> What I get is -1(binding), and irrelevant comments like "someone needs to
> migrate".
> Thank you. I know someone needs to do that.
>
> The Git repository with the full log4j 1.x history already exists.
> I highlighted it on a "[VOTE] Move log4j 1.x from SVN to Git" thread:
> https://lists.apache.org/thread/0z34x9536mtr2z98m4s4dpqglzvjhjfq
>
> Vladimir


Re: Configuration element for system properties

2021-12-20 Thread Matt Sicker
Without additional refactoring, the only way this would work is if the
logging config is the only config in the application. System
properties are global to the JVM. There's already a properties file
you can include that gets loaded as a log4j2 system properties file,
by the way.

On Mon, Dec 20, 2021 at 1:19 PM Gary Gregory  wrote:
>
> Hello,
>
> I'd like to propose that we add an element called SystemProperty to
> our configuration. This would look like our current Property element
> but would set a system property instead of a configuration property.
>
> My use case is, at work, our tooling generates one XML configuration
> file for a user's project and additional XML files for each DTAP
> environment. The main Log4j configuration file uses XInclude to bring
> in the appropriate DTAP file. Depending on the configuration of the
> user's project, and in light of Log4j's use of system properties,
> specifically, our new enableJndi* system properties, it would be nice
> to be able to say in DTAP XML files something like  key="enableJndiJms>true or whatever Property
> supports.
>
> Thoughts?
>
> Gary


Re: Resurrecting log4j 1.x

2021-12-20 Thread Vladimir Sitnikov
Ralph>I have no problem doing stuff on GitHub

Bingo!
That is what I said earlier.

It is really really demotivating that "PMC is not against".
I suggested the move. Neither Ralph nor Matt welcomed the change with +1.

At no time do I request you to perform the Git migration.
At no time do I request you to refactor the build scripts.
Yet you do ask A LOT before you even try doing something.

That is exactly the reason I believe it is way less time consuming for all
the parties to re-incubate 1.x
rather than keep all those "But someone needs to migrate".

Ralph>But someone needs to migrate it from SVN and I don’t have the time
for that

I can do that just fine. Would you just approve the move?
Is it really that hard to respond with +1 on move to Git thread?
What I get is -1(binding), and irrelevant comments like "someone needs to
migrate".
Thank you. I know someone needs to do that.

The Git repository with the full log4j 1.x history already exists.
I highlighted it on a "[VOTE] Move log4j 1.x from SVN to Git" thread:
https://lists.apache.org/thread/0z34x9536mtr2z98m4s4dpqglzvjhjfq

Vladimir


Configuration element for system properties

2021-12-20 Thread Gary Gregory
Hello,

I'd like to propose that we add an element called SystemProperty to
our configuration. This would look like our current Property element
but would set a system property instead of a configuration property.

My use case is, at work, our tooling generates one XML configuration
file for a user's project and additional XML files for each DTAP
environment. The main Log4j configuration file uses XInclude to bring
in the appropriate DTAP file. Depending on the configuration of the
user's project, and in light of Log4j's use of system properties,
specifically, our new enableJndi* system properties, it would be nice
to be able to say in DTAP XML files something like 

Re: Resurrecting log4j 1.x

2021-12-20 Thread Ralph Goers
I have no problem doing stuff on GitHub. Creating a repo is easy. But someone 
needs to migrate it from SVN and I don’t have the time for that. If someone 
puts up a repo at GitHub with all the history I’d be happy to create it under 
the logging project.

Ralph



> On Dec 20, 2021, at 12:08 PM, Vladimir Sitnikov  
> wrote:
> 
> Matt>I'm not against applying patches to the svn repo, either.
> 
> How about pull requests at GitHub?
> 
> Vladimir



Re: Resurrecting log4j 1.x

2021-12-20 Thread Vladimir Sitnikov
Matt>I'm not against applying patches to the svn repo, either.

How about pull requests at GitHub?

Vladimir


Re: Resurrecting log4j 1.x

2021-12-20 Thread Matt Sicker
I'm not against applying patches to the svn repo, either. I haven't
forgotten how to use svn as I still use it for Secretary stuff (plus
where we put release artifacts). Given that a PMC member would need to
do part of the release anyways, that hopefully isn't a blocker.

I'm +1 for making a minimal 1.2.18 release to address CVEs. If there
are any major bugs that have a simple fix, those might also qualify,
but I wouldn't recommend spending much time there. Log4j 1.x has some
intractable bugs that were only fixed in subsequent projects like
Log4j 2.x and Logback.

On Mon, Dec 20, 2021 at 12:39 PM Andrii Berezovskyi  wrote:
>
> Dear Vladimir,
>
> > When it comes to code-related changes, the reviews are vague, and it is
> > really hard (impossible?) to find consensus.
> I somehow got an idea that ripping out classes that could lead to a 
> NoClassDefFoundError for existing users did not fit the definition of "binary 
> compability" for the log4j2 committers. As much as I would love to rip the 
> classes in question out, I must admit that doing so is not binary compatible.
>
> And if I recall correctly, the request on 
> https://github.com/apache/log4j/pull/17 was to separate build changes from 
> the code fixes and start with a PR to fix one CVE only (and have that fix to 
> be something else than removing a class) so that can be reviewed in 
> reasonable time. And if I read between the lines well, the committers wanted 
> to see viable PRs before doing infra work that you are (correctly) 
> suggesting. But apologies for butting in if I got something wrong.
>
> Best regards,
> Andrew


SocketAppenderReconnectTest still flaky on mac 11.8.1; raising timeout to 15 sec helps

2021-12-20 Thread Dan Kegel
My build procedure for the release-2.x branch succeeded on mac
10.16.7, but is failing one lousy test on mac 11.8.1:

SocketAppenderReconnectTest.reconnect_should_fallback_when_there_are_multiple_resolved_hosts:129->verifyLoggingSuccess:192->awaitUntilSucceeds:219
» ConditionTimeout

I think https://github.com/apache/logging-log4j2/commit/b3e8818a111d884d1fbfe
wasn't sufficient.
Going with the same timeout as on windows seemed to work, i.e.

--- 
a/log4j-core/src/test/java/org/apache/logging/log4j/core/net/SocketAppenderReconnectTest.java
+++ 
b/log4j-core/src/test/java/org/apache/logging/log4j/core/net/SocketAppenderReconnectTest.java
@@ -211,7 +211,7 @@ class SocketAppenderReconnectTest {
 } else {
 // Universally sensible values.
 pollIntervalMillis = 1000;
-timeoutSeconds = 3;
+timeoutSeconds = 15;
 }
 await()
 .pollInterval(pollIntervalMillis, TimeUnit.MILLISECONDS)

There's something about even nice fast corporate hex-core i7 macbooks
that is slow these days, I dunno.
- Dan


Re: Resurrecting log4j 1.x

2021-12-20 Thread Andrii Berezovskyi
Dear Vladimir,

> When it comes to code-related changes, the reviews are vague, and it is
> really hard (impossible?) to find consensus.
I somehow got an idea that ripping out classes that could lead to a 
NoClassDefFoundError for existing users did not fit the definition of "binary 
compability" for the log4j2 committers. As much as I would love to rip the 
classes in question out, I must admit that doing so is not binary compatible.

And if I recall correctly, the request on 
https://github.com/apache/log4j/pull/17 was to separate build changes from the 
code fixes and start with a PR to fix one CVE only (and have that fix to be 
something else than removing a class) so that can be reviewed in reasonable 
time. And if I read between the lines well, the committers wanted to see viable 
PRs before doing infra work that you are (correctly) suggesting. But apologies 
for butting in if I got something wrong.

Best regards,
Andrew

Re: Resurrecting log4j 1.x

2021-12-20 Thread Ralph Goers
Vladimir,

The PMC is totally focused on resolving issues for log4j 2 at the moment. We 
are still getting tons
of emails you can’t see. So if it seems like we are being unhelpful it is 
entirely because we are 
focused on that.

We’ve stated several times that we don’t think resurrecting Log4j 1.x 
permanently is a good idea. 
Besides the vulnerabilities the code has serious threading issues that cannot 
be fixed with Log4j 1’s 
architecture. While I wasn’t on the Logging Services PMC when discussions about 
what to do 
were going on I read the email threads. There were many discussions about 
breaking compatibility 
that no one wanted to do, which is ultimately how SLF4J and Logback came into 
existence. 
If you are interested in that sort of thing you can go read to log4j dev list 
from 15 years or so ago. 

By the time I joined the Logging Services PMC most log4j 1.x development had 
stopped. Some 
of the contributors were still around but no one was doing much of anything.

The point of this is that we aren’t against fixing the CVEs in Log4j 1, but not 
by having stuff fail 
because the class is no longer there. JNDI can be scaled down as we have done 
in Log4j 2. The 
log server could prevent deserialization of unknown or arbitrary classes. Etc.

Ralph


> On Dec 20, 2021, at 10:59 AM, Vladimir Sitnikov  
> wrote:
> 
> Ron>wouldn't a more efficient approach be to offer support to
> Ron>Logging Services
> 
> Ron,
> I did try my best to offer my help with updating log4j 1.x.
> Unfortunately, I failed and none of Logging Services PMC accepted it.
> Here are the facts:
> https://lists.apache.org/thread/6lhkyytvpg4md757tfydb1k0mmp5j1oc
> 
> Ron>Re-starting the entire EOL'ed Log4j1
> Ron>engine with a new crew to fix one issue is confusing
> 
> It is confusing for me as well, however, the current crew does seem to
> cooperate
> regarding the changes to 1.x.
> 
> Ron>I don't get the sense folks are against fixing things
> 
> 1) There are multiple known open CVEs in log4j 1.x. The team is not really
> fixing known security issues.
> 2) All the responses from the current PMC are behind the lines of
> "evangelizing 2.x"
> rather than suggesting a way to fix 1.x and release it.
> 
> Ron>To answer your
> Ron>question about sponsorship, I want to explore partnering with Logging
> Ron>Services before forming a new Log4j1 team.
> 
> For example, my very basic suggestion was "let's move 1.x to Git for easier
> contribution",
> however, none of the PMC members approved the change.
> 
> When it comes to code-related changes, the reviews are vague, and it is
> really hard (impossible?) to find consensus.
> On top of that, the review is complicated by the fact that **multiple**
> fixes are needed for log4j 1.x
> 1) There are multiple known CVEs regarding 1.x
> 2) 1.x uses a really old build system, so, in my opinion, the build scripts
> should be updated before any other changes
> 
> Vladimir



Re: Resurrecting log4j 1.x

2021-12-20 Thread Vladimir Sitnikov
Ron>wouldn't a more efficient approach be to offer support to
Ron>Logging Services

Ron,
I did try my best to offer my help with updating log4j 1.x.
Unfortunately, I failed and none of Logging Services PMC accepted it.
Here are the facts:
https://lists.apache.org/thread/6lhkyytvpg4md757tfydb1k0mmp5j1oc

Ron>Re-starting the entire EOL'ed Log4j1
Ron>engine with a new crew to fix one issue is confusing

It is confusing for me as well, however, the current crew does seem to
cooperate
regarding the changes to 1.x.

Ron>I don't get the sense folks are against fixing things

1) There are multiple known open CVEs in log4j 1.x. The team is not really
fixing known security issues.
2) All the responses from the current PMC are behind the lines of
"evangelizing 2.x"
rather than suggesting a way to fix 1.x and release it.

Ron>To answer your
Ron>question about sponsorship, I want to explore partnering with Logging
Ron>Services before forming a new Log4j1 team.

For example, my very basic suggestion was "let's move 1.x to Git for easier
contribution",
however, none of the PMC members approved the change.

When it comes to code-related changes, the reviews are vague, and it is
really hard (impossible?) to find consensus.
On top of that, the review is complicated by the fact that **multiple**
fixes are needed for log4j 1.x
1) There are multiple known CVEs regarding 1.x
2) 1.x uses a really old build system, so, in my opinion, the build scripts
should be updated before any other changes

Vladimir


Re: Forwarding email per Matt Sicker suggestion

2021-12-20 Thread Ralph Goers
Thanks Dick,

I am totally unfamiliar with this. Is there somewhere to read about what this 
is all about?

Ralph

> On Dec 20, 2021, at 7:18 AM, Dick Brooks  
> wrote:
> 
> Hello,
>  
> This sort of suggestion would be better sent to our development mailing list 
> (dev@logging.apache.org ). I’ll note that we 
> use Apache Maven for our build system, and a quick search shows that 
>  > might be a useful 
> plugin to propose for generating the SBOM as part of our standard release 
> process. I do think it’s a good idea, but this topic should be discussed in 
> our public list and not on the private list.
> --
> Matt Sicker 
> 
> 
> On Dec 19, 2021, at 12:48, Dick Brooks  > wrote:
>  
> I’ve created an SPDX SBOM for Log4j V 2.17.0-core along with a companion 
> baseline vulnerability disclosure report (VDR), based on NIST NVD search 
> results:
> https://github.com/rjb4standards/REA-Products/tree/master/Log4jUseCase 
> 
>  
> Please read the README.md first to understand the limitations of this info.
>  
> I encourage the Log4j team to consider updating the FixStatus and 
> AnalysisFindings elements for each reported CVE. I’m happy to assist in this 
> effort.
>  
> Thanks,
>  
> Dick Brooks
> 
> Never trust software, always verify and report! 
>  ™
> http://www.reliableenergyanalytics.com 
> 
> Email: d...@reliableenergyanalytics.com 
> 
> Tel: +1 978-696-1788
>  
>  
>  
> Thanks,
>  
> Dick Brooks
> 
> Never trust software, always verify and report! 
>  ™
> http://www.reliableenergyanalytics.com 
> 
> Email: d...@reliableenergyanalytics.com 
> 
> Tel: +1 978-696-1788



Forwarding email per Matt Sicker suggestion

2021-12-20 Thread Dick Brooks
Hello,

 

This sort of suggestion would be better sent to our development mailing list
(dev@logging.apache.org  ). I'll note that we
use Apache Maven for our build system, and a quick search shows that
 might be a useful
plugin to propose for generating the SBOM as part of our standard release
process. I do think it's a good idea, but this topic should be discussed in
our public list and not on the private list.

--
Matt Sicker 





On Dec 19, 2021, at 12:48, Dick Brooks mailto:d...@reliableenergyanalytics.com> > wrote:

 

I've created an SPDX SBOM for Log4j V 2.17.0-core along with a companion
baseline vulnerability disclosure report (VDR), based on NIST NVD search
results:

 
https://github.com/rjb4standards/REA-Products/tree/master/Log4jUseCase

 

Please read the README.md first to understand the limitations of this info.

 

I encourage the Log4j team to consider updating the FixStatus and
AnalysisFindings elements for each reported CVE. I'm happy to assist in this
effort.

 

Thanks,

 

Dick Brooks



  Never trust software, always
verify and report! T

 
http://www.reliableenergyanalytics.com

Email:  
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

 

 

Thanks,

 

Dick Brooks



  Never trust software, always
verify and report! T

 
http://www.reliableenergyanalytics.com

Email:  
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 



Re: Building log4j from source on mac? (toolchain.xml madness!)

2021-12-20 Thread Dan Kegel
Thank you, that was very helpful.

For completeness, here is the script that seems to work for me; at
least, maven runs to completion.
(Might want to remove the jdk 7 section from toolchains-sample-mac.xml
in git...?)

http://kegel.com/install-log4j2-mac.sh.txt

- Dan

On Sun, Dec 19, 2021 at 10:19 PM Ralph Goers  wrote:
>
> Also, make sure you are building the release-2.x branch. The master branch 
> will build with Maven and targets Java 11 but it u
> ses some strange mechanics to get around the quirks of JPMS and this will 
> make it a mess in your IDE.  Once things get back
> to normal I plan to fix up the master branch using suggestions we got from 
> the Maven team.
>
> Ralph
>
> > On Dec 19, 2021, at 11:15 PM, Ralph Goers  
> > wrote:
> >
> > You must run the build with Java 8 as the default JDK. You need a toolchain 
> > for Java 9 or greater. I’d recommend Java 11.
> >
> > Ralph
> >
> >> On Dec 19, 2021, at 10:53 PM, Dan Kegel  wrote:
> >>
> >> Hi all!
> >>
> >> I'm trying to write an ide-free shell script to reproducibly build log4j 
> >> from
> >> git on a fresh mac, following
> >> https://logging.apache.org/log4j/2.x/build.html and filling in the
> >> blanks.  My current draft,
> >> http://kegel.com/install-log4j2-mac.sh.txt
> >> installs 
> >> https://download.oracle.com/java/17/latest/jdk-17_macos-x64_bin.dmg
> >> and creates a toolchains.xml file:
> >> sed 's/java[789]/jdk-17.0.1.jdk/' < toolchains-sample-mac.xml >
> >> ~/.m2/toolchains.xml
> >>
> >> Not too surprisingly, that fails with
> >>
> >> [ERROR] Failed to execute goal
> >> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:testCompile
> >> (default-testCompile) on project log4j-api: Compilation failure
> >> [ERROR] 
> >> /Users/dank/logdemo/logging-log4j2/log4j-api/src/test/java/org/apache/logging/log4j/util/StackLocatorUtilTest.java:[25,18]
> >> error: cannot find symbol
> >> [ERROR]   symbol:   class Reflection
> >> [ERROR]   location: package sun.reflect
> >>
> >> I dimly recall sun.reflect going away (
> >> https://stackoverflow.com/questions/23808803/sun-reflect-reflection-getcallerclass-alternative
> >> says it was removed from jdk8), so perhaps the way my script sets up
> >> ~/.m2/toolchain.xml isn't sufficient.  Is one supposed to add
> >> something to toolchain.xml to tell javac to target a different version
> >> of the jdk in each of the jdk7/8/9 sections?  Or do I actually have to
> >> go dig up an ancient JDK 1.7 to make maven and log4j happy?
> >>
> >> https://blog.hcf.dev/article/2019-09-15-maven-toolchains-xml-script
> >> suggests the latter, ugh...
> >>
> >> Thanks,
> >> Dan Kegel
> >>
> >
> >
>
#!/bin/sh
# Building log4j2 2.x from scratch on Mac
set -ex

# Running "javac --version" points you to this download page if no javac is 
installed
if ! test -d /Library/Java/JavaVirtualMachines/jdk-17.0.1.jdk
then
if ! test -f jdk-17_macos-x64_bin.dmg
then
wget 
https://download.oracle.com/java/17/latest/jdk-17_macos-x64_bin.dmg
fi
open jdk-17_macos-x64_bin.dmg
sudo installer -pkg /Volumes/JDK\ 17.0.1/JDK\ 17.0.1.pkg -target /
fi
javac --version

if ! test -d /Library/Java/JavaVirtualMachines/jdk1.8.0_202.jdk
then
if ! test -f $HOME/Downloads/jdk-17_macos-x64_bin.dmg
then
open 
https://www.oracle.com/java/technologies/javase/javase8-archive-downloads.html#license-lightbox
while ! test -f $HOME/Downloads/jdk-8u202-macosx-x64.dmg
do
sleep 1
done
fi
open $HOME/Downloads/jdk-8u202-macosx-x64.dmg
sudo installer -pkg "/Volumes/JDK 8 Update 202/JDK 8 Update 202.pkg" 
-target /
fi
javac --version

if ! test -d apache-maven-2.8.4
then
# See https://maven.apache.org/install.html
if ! test -f apache-maven-3.8.4-bin.tar.gz
then
wget 
https://dlcdn.apache.org/maven/maven-3/3.8.4/binaries/apache-maven-3.8.4-bin.tar.gz
fi
tar -xf apache-maven-3.8.4-bin.tar.gz
fi
PATH=$PWD/apache-maven-3.8.4/bin:$PATH
mvn --version

if ! test -f ~/.m2/toolchains.xml
then
mkdir -p ~/.m2
cat > ~/.m2/toolchains.xml << "_EOF_"


  
jdk

  1.8
  sun


  
/Library/Java/JavaVirtualMachines/jdk1.8.0_202.jdk/Contents/Home

  
  
jdk

  17
  sun


  
/Library/Java/JavaVirtualMachines/jdk-17.0.1.jdk/Contents/Home

  

_EOF_
fi

if ! test -d logging-log4j2
then
# See https://logging.apache.org/log4j/2.x/build.html
git clone --branch release-2.x https://github.com/apache/logging-log4j2
fi
# Make 1.8 the default java for this build
export JAVA_HOME=$(/usr/libexec/java_home -v 1.8.0_202)
cd logging-log4j2
mvn install


Re: Resurrecting log4j 1.x

2021-12-20 Thread Ron Grabowski
Vladimir, wouldn't a more efficient approach be to offer support to 
Logging Services then have them make a release to address the recent CVE 
while still maintaining 1.2.17 compatibility? I don't get the sense 
folks are against fixing things. Re-starting the entire EOL'ed Log4j1 
engine with a new crew to fix one issue is confusing. To answer your 
question about sponsorship, I want to explore partnering with Logging 
Services before forming a new Log4j1 team.


On 12/20/2021 11:15 AM, Gary Gregory wrote:

I don't see the need for the incubator or a new PMC, this is a recipe for
confusion for users and contributors: Log4j 1 is a component of the Apache
Logging Services project and should remain for Apache to provide the best
and consistent *story* for Java logging, at Apache at least.

Things are bad enough when a product or projects offers pluggable logging
and I have have to explain facades like Log4j API, Jetty Logging, slf4j,
etc, and then implementations of APIs like Log4j Core, Logback, etc, and
then explain when and how to use bridges.

I wrote the above to make the point that reintroducing log4j 1 as a first
class citizen is going to make an even bigger and confusing mess.

The only work we should allow is a 1.2.x release that fixes CVEs.

We should continue to evangelize migration to 2.x.

Gary


On Mon, Dec 20, 2021, 09:36 Ralph Goers  wrote:


I am sure any number of PMC members would be happy to act as sponsors &
mentors. However, before
you even start you need to know if you have enough people who want to
participate tin the project. The
application form needs to include the list of names of people who will
become the initial members of the project.

The reason I brought this up is that it seems there are two groups here.
One that wants to get a release
out and then put Log4j 1 back in the coffin and another that wants to
resurrect it.

Ralph



On Dec 20, 2021, at 7:06 AM, Vladimir Sitnikov <

sitnikov.vladi...@gmail.com> wrote:

Ron,

There's a need to move log4j 1.x forward, and Ralph Goers suggested
that the way to go is to re-incubate it, see [1].

Could you sponsor the project or do you want Incubator to do that? (see

[2])

[1]: https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5
[2]: https://lists.apache.org/thread/c2362g4m4m4y1n7zl444ncvhmfb9oy0m

Vladimir




Re: Resurrecting log4j 1.x

2021-12-20 Thread Gary Gregory
I don't see the need for the incubator or a new PMC, this is a recipe for
confusion for users and contributors: Log4j 1 is a component of the Apache
Logging Services project and should remain for Apache to provide the best
and consistent *story* for Java logging, at Apache at least.

Things are bad enough when a product or projects offers pluggable logging
and I have have to explain facades like Log4j API, Jetty Logging, slf4j,
etc, and then implementations of APIs like Log4j Core, Logback, etc, and
then explain when and how to use bridges.

I wrote the above to make the point that reintroducing log4j 1 as a first
class citizen is going to make an even bigger and confusing mess.

The only work we should allow is a 1.2.x release that fixes CVEs.

We should continue to evangelize migration to 2.x.

Gary


On Mon, Dec 20, 2021, 09:36 Ralph Goers  wrote:

> I am sure any number of PMC members would be happy to act as sponsors &
> mentors. However, before
> you even start you need to know if you have enough people who want to
> participate tin the project. The
> application form needs to include the list of names of people who will
> become the initial members of the project.
>
> The reason I brought this up is that it seems there are two groups here.
> One that wants to get a release
> out and then put Log4j 1 back in the coffin and another that wants to
> resurrect it.
>
> Ralph
>
>
> > On Dec 20, 2021, at 7:06 AM, Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote:
> >
> > Ron,
> >
> > There's a need to move log4j 1.x forward, and Ralph Goers suggested
> > that the way to go is to re-incubate it, see [1].
> >
> > Could you sponsor the project or do you want Incubator to do that? (see
> [2])
> >
> > [1]: https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5
> > [2]: https://lists.apache.org/thread/c2362g4m4m4y1n7zl444ncvhmfb9oy0m
> >
> > Vladimir
>
>


Re: Resurrecting log4j 1.x

2021-12-20 Thread Gary Gregory
"need to move log4j 1.x forward"

If this means more than only fixing CVEs it will create a giant hairball of
confusion for users between 1.x and 2.x.

Gary

On Mon, Dec 20, 2021, 09:06 Vladimir Sitnikov 
wrote:

> Ron,
>
> There's a need to move log4j 1.x forward, and Ralph Goers suggested
> that the way to go is to re-incubate it, see [1].
>
> Could you sponsor the project or do you want Incubator to do that? (see
> [2])
>
> [1]: https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5
> [2]: https://lists.apache.org/thread/c2362g4m4m4y1n7zl444ncvhmfb9oy0m
>
> Vladimir
>


Re: CVE-2021-45105 and using ctx for router appender

2021-12-20 Thread Leon Finker
Thank you Ralph! Yes we never drive ${cx:Key} from any input. It's
either hardcoded or comes from controlled configuration.

On Mon, Dec 20, 2021 at 9:10 AM Leon Finker  wrote:
>
> Hi,
>
> Could someone please confirm if using ctx in the Routing appender is
> not affected by the latest CVE-2021-45105?
>
> Example,
> 
>  
>
> I wouldn't think so. Just want to double check.
>
> Thank you very much!


Re: Zero-copy rolling files

2021-12-20 Thread Tim Perry
Junctions are nice, but I think they are limited to pointing to directories on 
local file systems. Symlinks can point to remote files and directories on local 
or remote file systems (including using UNC paths). 

I didn’t bring up the windows permissions issue with symlinks because I think 
it is a stopper, I brought it up because we’ll need to include information 
about the minimal permissions needed to use the feature. It’s normal to request 
fine grained permissions for an application in a windows environment; I don’t 
think this would give anyone pause. 

Tim

> On Dec 19, 2021, at 2:16 PM, Matt Sicker  wrote:
> I think the NIO API for symlinks on Windows correspond to the ones that 
> require admin permissions to create. There are also file junctions that are a 
> feature of NTFS, though I’m not sure if there’s any way to create them 
> besides invoking cmd and running a mklink command from there (which, as it 
> might sound, requires a few layers of encoding to properly invoke). For more 
> info, take a look at 
> https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/os/WindowsUtil.java
>  
> 
>  where I first encountered this filesystem madness due to an old security 
> vulnerability we fixed in the Jenkins project years ago and ended up writing 
> most of the code I’m talking about.
> --
> Matt Sicker
> 
>> On Dec 19, 2021, at 08:33, Gary Gregory  wrote:
>> 
>>> On Sun, Dec 19, 2021 at 9:03 AM Jochen Wiedmann
>>>  wrote:
>>> Having worked with symbolic links on Windows a lot, I find that
>>> privileges are present, in most cases. However, there is the technical
>>> question "How do I create them?"
>> 
>> java.nio.file.Files.createSymbolicLink(Path, Path, FileAttribute...)
>> 
>> The API is documented as an optional operation so we might need a set
>> of OS-specific calls to Runtime.exec(String).
>> 
>> Gary
>> 
>>> The best solution, that I have found so far is letting "cmd" do the
>>> job for me. (The mklink command is not a separate executable, but
>>> build into cmd.)
>>> https://github.com/jochenw/afw/blob/master/afw-core/src/main/java/com/github/jochenw/afw/core/components/WindowsCmdSymbolicLinksHandler.java
>>> Jochen
>>> On Sat, Dec 18, 2021 at 7:43 PM Tim Perry  wrote:
 I like this idea, but I think it would require non-default permissions for 
 the account the application runs under on windows. However, it could be 
 feature that can be switched on.
 https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/create-symbolic-links
 Maybe I read the docs from MS incorrectly.
 Tim
> On Dec 18, 2021, at 7:07 AM, Gary Gregory  wrote:
> Hi All:
> And now for something completely different.
> I wonder why we do not do file rollovers like below, and if we should:
> - Create the file with the target rolled over a name like applog-2021.txt
> - Create a symlink for the constant name like applog.txt to point to
> applog-2021.txt
> - When it's rollover time, start writing to the new file
> applog-2022.txt and change the symlink to point to it.
> Zero copy.
> Thoughts?
> Gary
>>> --
>>> Philosophy is useless, theology is worse. (Industrial Desease, Dire Straits)


Re: Resurrecting log4j 1.x

2021-12-20 Thread Ralph Goers
Yes, that is certainly a possibility. For that I don’t think a trip through the 
incubator would be necessary. 
But it would also be difficult to make the folks working on log4j 1.x 
committers of the Logging Services 
project since gaining commit rights to an ASF project usually requires more 
than just submitting one or 
two patches.

Ralph

> On Dec 20, 2021, at 8:03 AM, Andrii Berezovskyi  wrote:
> 
> Dear Ralph,
> 
>> The reason I brought this up is that it seems there are two groups here. One 
>> that wants to get a release 
>> out and then put Log4j 1 back in the coffin and another that wants to 
>> resurrect it.
> 
> Do you think there may be a middle ground here? In other words, users who 
> think that log4j is "done" and does not need new features, but at the same 
> time realise that new security issues could pop up in the future and require 
> a release done quickly once a year or so?
> 
> Best regards,
> Andrew
> 
> 



Re: Resurrecting log4j 1.x

2021-12-20 Thread Andrii Berezovskyi
Dear Ralph,

> The reason I brought this up is that it seems there are two groups here. One 
> that wants to get a release 
> out and then put Log4j 1 back in the coffin and another that wants to 
> resurrect it.

Do you think there may be a middle ground here? In other words, users who think 
that log4j is "done" and does not need new features, but at the same time 
realise that new security issues could pop up in the future and require a 
release done quickly once a year or so?

Best regards,
Andrew



Re: Resurrecting log4j 1.x

2021-12-20 Thread Vladimir Sitnikov
The key question is who will be the sponsor: Logging or Incubator.

>However, before you even start you need to know
>if you have enough people who want to participate tin the project

I'm sure there are 3-5 persons that would be willing to cooperate.

Vladimir


Re: CVE-2021-45105 and using ctx for router appender

2021-12-20 Thread Ralph Goers
Using ${cx:Key} should not be used in releases below 2.16.0 in a routing key - 
or anything else 
that operates during log event processing - IF the key contains data that 
originates externally.

So if your key contains data from an HTTP header and you copy that data into a 
ThreadContext 
variable using that as a routing key could expose your application to bad 
behavior. In Log4j 2.17.0 
we have prevented lookups used while processing log events from recursing but 
even then if you
have a user sending you bogus stuff your routing key may create a route for 
each unique key, 
depending on how you configured your routes.

If you must use HTTP headers in this way you should “sanitize” then in a 
Servlet Filter before 
they hit your application, only allowing headers that match the “rules” for 
whatever the data is. 

Ralph

> On Dec 20, 2021, at 7:10 AM, Leon Finker  wrote:
> 
> Hi,
> 
> Could someone please confirm if using ctx in the Routing appender is
> not affected by the latest CVE-2021-45105?
> 
> Example,
> 
> 
> 
> I wouldn't think so. Just want to double check.
> 
> Thank you very much!
> 



CVE-2021-45105 and using ctx for router appender

2021-12-20 Thread Leon Finker
Hi,

Could someone please confirm if using ctx in the Routing appender is
not affected by the latest CVE-2021-45105?

Example,

 

I wouldn't think so. Just want to double check.

Thank you very much!


Re: Resurrecting log4j 1.x

2021-12-20 Thread Ralph Goers
I am sure any number of PMC members would be happy to act as sponsors & 
mentors. However, before 
you even start you need to know if you have enough people who want to 
participate tin the project. The 
application form needs to include the list of names of people who will become 
the initial members of the project.

The reason I brought this up is that it seems there are two groups here. One 
that wants to get a release 
out and then put Log4j 1 back in the coffin and another that wants to resurrect 
it.

Ralph


> On Dec 20, 2021, at 7:06 AM, Vladimir Sitnikov  
> wrote:
> 
> Ron,
> 
> There's a need to move log4j 1.x forward, and Ralph Goers suggested
> that the way to go is to re-incubate it, see [1].
> 
> Could you sponsor the project or do you want Incubator to do that? (see [2])
> 
> [1]: https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5
> [2]: https://lists.apache.org/thread/c2362g4m4m4y1n7zl444ncvhmfb9oy0m
> 
> Vladimir



Re: [logging-log4j2] branch java6 created (now a0b0e11)

2021-12-20 Thread Ralph Goers
OK. I originally tried log4j-2.3 as the branch name but that matched an 
existing tag. log4j-2.3.x should work though

Ralph

> On Dec 20, 2021, at 6:37 AM, Gary Gregory  wrote:
> 
> We need a better branch name IMO... one like the 2.12.x name, 2.12 ->
> 2.12.x? java6 -> 2.3.x?
> 
> Gary
> 
> On Mon, Dec 20, 2021, 00:45  wrote:
> 
>> This is an automated email from the ASF dual-hosted git repository.
>> 
>> rgoers pushed a change to branch java6
>> in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git.
>> 
>> 
>>  at a0b0e11  Create branch for security releases
>> 
>> This branch includes the following new commits:
>> 
>> new a0b0e11  Create branch for security releases
>> 
>> The 1 revisions listed above as "new" are entirely new to this
>> repository and will be described in separate emails.  The revisions
>> listed as "add" were already present in the repository and have only
>> been added to this reference.
>> 
>> 



Resurrecting log4j 1.x

2021-12-20 Thread Vladimir Sitnikov
Ron,

There's a need to move log4j 1.x forward, and Ralph Goers suggested
that the way to go is to re-incubate it, see [1].

Could you sponsor the project or do you want Incubator to do that? (see [2])

[1]: https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5
[2]: https://lists.apache.org/thread/c2362g4m4m4y1n7zl444ncvhmfb9oy0m

Vladimir


Re: [logging-log4j2] branch java6 created (now a0b0e11)

2021-12-20 Thread Gary Gregory
We need a better branch name IMO... one like the 2.12.x name, 2.12 ->
2.12.x? java6 -> 2.3.x?

Gary

On Mon, Dec 20, 2021, 00:45  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> rgoers pushed a change to branch java6
> in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git.
>
>
>   at a0b0e11  Create branch for security releases
>
> This branch includes the following new commits:
>
>  new a0b0e11  Create branch for security releases
>
> The 1 revisions listed above as "new" are entirely new to this
> repository and will be described in separate emails.  The revisions
> listed as "add" were already present in the repository and have only
> been added to this reference.
>
>


Re: [VOTE] Release log4net 2.0.14

2021-12-20 Thread Dominik Psenner
* old-log4net.snk.gpg has been the old key to sign binaries.
* @Matt, where is the root logging KEYS file located?

The changes in the release look good to me. +1

On Mon, 20 Dec 2021 at 07:34, Davyd McColl  wrote:

> Thanks Matt
>
> Since you've given a +1, I'll write up some sticky notes to address these
> points in the near future.
>
> -d
>
>
> On December 19, 2021 23:51:45 Matt Sicker  wrote:
>
> > +1
> >
> > Notes on the release:
> > * I’ve copied your release signing key to the root logging KEYS file for
> > easier discoverability.
> > * The copyright year in the NOTICE file is a few years out of date at
> this
> > point. I’ve updated this in master, though you’ll want to update this
> again
> > in a couple weeks when it’s outdated again.
> > * Some included files in the base directory of the source zip are
> missing
> > copyright headers or shouldn’t even be included in the tarball (e.g.,
> the
> > appveyor config file probably isn’t necessary)
> >   - Not sure what old-log4net.snk.gpg is in there for, either.
> >   - Gulp task source files missing headers
> > * Artifact signatures and sha512 hashes look good (checked with shasum
> > which is the Perl script version), contain appropriate LICENSE and
> NOTICE
> > (besides the outdated copyright year, but not a blocker), no binaries in
> > the source zip, appropriate files in the binary zip.
> >
> > --
> > Matt Sicker
> >
> >> On Dec 16, 2021, at 07:47, Davyd McColl  wrote:
> >>
> >> Hi all
> >>
> >> I'd like to raise a vote to release log4net 2.0.14. Changelog is up on
> the
> >> pre-release page at
> >> https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.14-rc1
> >>
> >> I have updated staging docs and I _think_ I've done the right thing with
> >> respect to getting binaries and source up to the dev repo at
> >> https://dist.apache.org/repos/dist/dev/logging, but the download links
> on
> >> the staging docs point to the release download area, so I'm not sure if
> I
> >> should rather upload there so that staging documentation "works as
> >> expected" for the vote to continue.
> >>
> >> Thanks Ralph for assisting me in being able to uplodate artifacts
> myself.
> >> Much appreciated.
> >>
> >> -d
> >>
> >> PS. This email is a duplicate of the one sent from my work email (
> >> davyd.mcc...@codeo.co.za) which I believe has been lost somewhere
> along the
> >> way. Please ignore the other if it pops up.
> >>
> >>
> >> --
> >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >> If you say that getting the money is the most important thing
> >> You will spend your life completely wasting your time
> >> You will be doing things you don't like doing
> >> In order to go on living
> >> That is, to go on doing things you don't like doing
> >>
> >> Which is stupid.
> >>
> >> - Alan Watts
> >> https://www.youtube.com/watch?v=-gXTZM_uPMY
> >>
> >> *Quidquid latine dictum sit, altum sonatur. *
> >
>


-- 
Dominik Psenner