Re: [log4cxx] How to run the throughput test?

[Thorsten Schöning]

Guten Tag Robert Middleton,
am Donnerstag, 30. Dezember 2021 um 00:24 schrieben Sie:

> After taking a look at this, maybe the best option is to add the
> throughput as a unit test so that we can set the path the same as the
> other unit tests?

If it fixes the path issue and enabling/disabling through the already
existing option works, sounds good to me.

> [...]You can
> also run individual tests through visual studio, so that might solve
> the problem.

This is possible with simply opening the source file of the throughput
test and choose to run it as well. Though, I wonder if CMAKE doesn't
properly take things like the "$" into
account then, because that part is simply not built when directly
running the throughput test as app only.

That might be different in the context of running all or individual
unit tests.

> On Windows, I manually copied troughputtests.exe to the installation
> directory (so log4cxx.dll is in the same directory).

I would like to avoid that and instead either copy the DLL into the
working dir of the throughput test or preferrably adopt the path to
the DLL based on that working dir. Something like the following:

> [...]\master\src\out\build\x64-Debug\src\main\cpp\log4cxx.dll
> set(LOG4CXX_DLL_DIR "$>;")

vs.

> [...]\master\src\out\build\x64-Debug\src\test\cpp\throughput\log4cxx.dll
> set(LOG4CXX_DLL_DIR 
> "$\..\..\..\main\cpp>;")

Mit freundlichen Grüßen

Thorsten Schöning

-- 
AM-SoFT IT-Service - Bitstore Hameln GmbH
Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK

E-Mail: thorsten.schoen...@am-soft.de
Web:http://www.AM-SoFT.de/

Tel:   05151-  9468- 0
Tel:   05151-  9468-55
Fax:   05151-  9468-88
Mobil:  0178-8 9468-04

AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska

Re: rat:check at verify

[Volkan Yazıcı]

Pushed to both `release-2.x` and `master`.

On Wed, Dec 29, 2021 at 10:25 AM Volkan Yazıcı  wrote:

> I suggest hooking apache-rat:check up to the verify stage in Maven. This
> will make CI run that goal too. Objections?
>

Re: Published artifact hash files

[Remko Popma]

I agree that would be great.
Meanwhile, I am using this script/command to achieve the same result:

for a in 1 256 512; do
  for f in `find . -type f -name "*.sha${a}"`; do
claim=`cat $f |cut -d' ' -f1`;
actual=`shasum ${f%.sha*} -a ${a} |cut -d' ' -f1`;
if [[ "$claim" == "$actual" ]]; then echo " OK $f" ; else echo " FAIL
$f"; fi;
  done
done

for f in `find . -type f -name "*.asc"`; do if gpg 2>&1 --verify $f |grep
-q "Good sig" ; then echo " OK $f" ; else echo " FAIL $f"; fi ; done



On Thu, Dec 30, 2021 at 3:19 AM Gary Gregory  wrote:

> That would be great.
>
> Gary
>
> On Wed, Dec 29, 2021, 12:54 Matt Sicker  wrote:
>
> > The SHA files are generated via a Maven plugin that only outputs the
> hash,
> > not the filename. Looks like we need to figure out how to configure that.
> > --
> > Matt Sicker
> >
> > > On Dec 29, 2021, at 02:53, Volkan Yazıcı  wrote:
> > >
> > > Certain hash files are not properly formatted (see below), can we (I?)
> > fix
> > > this?
> > >
> > > wget \
> > >  --quiet \
> > >  --execute robots=off \
> > >  --timestamping \
> > >  --cut-dirs=7 \
> > >  --no-host-directories \
> > >  --recursive \
> > >  --page-requisites \
> > >  --no-parent \
> > >  --no-check-certificate \
> > >  https://dist.apache.org/repos/dist/dev/logging/log4j/
> > >
> > > for sha_alg in 256 512; do
> > >  find . -type f -name "*.sha$sha_alg" | while read sha_file; do
> > >shasum --algorithm $sha_alg --check "$sha_file"
> > >  done
> > > done
> > >
> > > apache-log4j-api-scala-13.0-src.tar.gz: OK
> > > apache-log4j-api-kotlin-1.2.0-bin.tar.gz: OK
> > > apache-log4j-api-scala-13.0-src.zip: OK
> > > apache-log4j-api-kotlin-1.2.0-bin.zip: OK
> > > shasum: ./apache-log4j-2.12.4-src.tar.gz.sha256: no properly formatted
> > SHA
> > > checksum lines found
> > > shasum: ./apache-log4j-2.12.4-bin.zip.sha256: no properly formatted SHA
> > > checksum lines found
> > > apache-log4j-api-kotlin-1.2.0-src.zip: OK
> > > apache-log4j-api-kotlin-1.2.0-bin.tar.bz2: OK
> > > apache-log4j-api-scala-13.0-bin.zip: OK
> > > shasum: ./apache-log4j-2.3.2-src.zip.sha256: no properly formatted SHA
> > > checksum lines found
> > > shasum: ./apache-log4j-2.3.2-bin.tar.gz.sha256: no properly formatted
> SHA
> > > checksum lines found
> > > apache-log4j-api-kotlin-1.2.0-src.tar.bz2: OK
> > > shasum: ./apache-log4j-2.12.4-bin.tar.gz.sha256: no properly formatted
> > SHA
> > > checksum lines found
> > > shasum: ./apache-log4j-2.12.4-src.zip.sha256: no properly formatted SHA
> > > checksum lines found
> > > apache-log4j-api-scala-13.0-bin.tar.gz: OK
> > > apache-log4j-api-kotlin-1.2.0-src.tar.gz: OK
> > > shasum: ./apache-log4j-2.3.2-src.tar.gz.sha256: no properly formatted
> SHA
> > > checksum lines found
> > > shasum: ./apache-log4j-2.12.4-src.zip.sha512: no properly formatted SHA
> > > checksum lines found
> > > apache-log4j-api-scala-13.0-bin.zip: OK
> > > apache-log4j-api-scala-13.0-bin.tar.gz: OK
> > > apache-log4j-api-scala-13.0-src.tar.gz: OK
> > > shasum: ./apache-log4j-2.12.4-bin.zip.sha512: no properly formatted SHA
> > > checksum lines found
> > > apache-log4j-api-kotlin-1.2.0-src.tar.gz: OK
> > > apache-log4j-api-kotlin-1.2.0-src.zip: OK
> > > shasum: ./apache-log4j-2.3.2-src.tar.gz.sha512: no properly formatted
> SHA
> > > checksum lines found
> > > shasum: ./apache-log4j-2.3.2-src.zip.sha512: no properly formatted SHA
> > > checksum lines found
> > > shasum: ./apache-log4j-2.12.4-src.tar.gz.sha512: no properly formatted
> > SHA
> > > checksum lines found
> > > apache-log4j-api-kotlin-1.2.0-bin.tar.gz: OK
> > > apache-log4j-api-kotlin-1.2.0-bin.tar.bz2: OK
> > > apache-log4j-api-scala-13.0-src.zip: OK
> > > apache-log4j-api-kotlin-1.2.0-src.tar.bz2: OK
> > > shasum: ./apache-log4j-2.3.2-bin.tar.gz.sha512: no properly formatted
> SHA
> > > checksum lines found
> > > shasum: ./apache-log4j-2.12.4-bin.tar.gz.sha512: no properly formatted
> > SHA
> > > checksum lines found
> > > shasum: ./apache-log4j-2.3.2-bin.zip.sha512: no properly formatted SHA
> > > checksum lines found
> > > apache-log4j-api-kotlin-1.2.0-bin.zip: OK
> >
> >
>

Re: [log4cxx] How to run the throughput test?

[Stephen Webb]

On Windows, I manually copied troughputtests.exe to the installation
directory (so log4cxx.dll is in the same directory).

Perhaps it should be installed by cmake when BUILD_THROUGHPUT_TESTS is on.


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Thu, Dec 30, 2021 at 10:25 AM Robert Middleton 
wrote:

> After taking a look at this, maybe the best option is to add the
> throughput as a unit test so that we can set the path the same as the
> other unit tests?  If it is not added as a unit test it won't be
> run(which is good), but if we enable the option it will run.  You can
> also run individual tests through visual studio, so that might solve
> the problem.  Looking at the CMakeLists.txt, it doesn't actually do
> anything with the path that it calculates, it's only building the exe.
>
> I did try to add a custom target, but that does not let you set the
> environment(which needs to be set for us to load the required DLLs
> from the PATH).
>
> -Robert Middleton
>
> On Wed, Dec 29, 2021 at 5:27 PM Stephen Webb  wrote:
> >
> > That looks like a cmake issue - could you try cmake version 3.22?
> >
> > I am still using Visual Studio 2019 Community Edition.
> >
> > <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> > Virus-free.
> > www.avast.com
> > <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >
> > On Thu, Dec 30, 2021 at 4:30 AM Robert Middleton 
> > wrote:
> >
> > > Perhaps we need to add a custom target to CMake to make it runnable?
> > > I think that would then hook into visual studio to make it easy to
> > > run; I'll try to take a look at it tonight.
> > >
> > > The part of the CMakeLists.txt file that does that was copy
> > > from one directory up, so it could be a directory level issue that I
> > > missed.
> > >
> > > -Robert Middleton
> > >
> > > On Wed, Dec 29, 2021 at 7:15 AM Thorsten Schöning <
> tschoen...@am-soft.de>
> > > wrote:
> > > >
> > > > Hi everyone,
> > > >
> > > > I just tried to run the throughput test: Installed FMT using VCPKG,
> > > > changed CMAKE to option that test ON and things built successfully.
> > > > Though, running fails because log4cxx.dll can't be found. In theory
> > > > CMAKE should already handle that using the following line:
> > > >
> > > > > set(LOG4CXX_DLL_DIR "$>;")
> > > >
> > > > Though, doesn't seem to work for my Windows and Visual Studio 2022.
> > > > The actual path of that DLL is the following:
> > > >
> > > > > [...]\master\src\out\build\x64-Debug\src\main\cpp\log4cxx.dll
> > > >
> > > > Using PROCMON I can see that the test tries to load the file from the
> > > > following LOG4CXX-specific directories instead:
> > > >
> > > > >
> > >
> [...]\master\src\out\build\x64-Debug\src\test\cpp\throughput\log4cxx.dll
> > > > >
> [...]\master\src\out\build\x64-Debug\src\test\cpp\helpers\log4cxx.dll
> > > >
> > > > Looking at the CMAKE file this somewhat makes sense, because at least
> > > > the first line is the target directory of the throughput test.
> > > >
> > > > How is your setup? Do you manually copy the DLL or are executing the
> > > > throughput test differently and Visual Studio makes a difference
> here?
> > > >
> > > > Mit freundlichen Grüßen
> > > >
> > > > Thorsten Schöning
> > > >
> > > > --
> > > > AM-SoFT IT-Service - Bitstore Hameln GmbH
> > > > Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT
> und
> > > TK
> > > >
> > > > E-Mail: thorsten.schoen...@am-soft.de
> > > > Web:http://www.AM-SoFT.de/
> > > >
> > > > Tel:   05151-  9468- 0
> > > > Tel:   05151-  9468-55
> > > > Fax:   05151-  9468-88
> > > > Mobil:  0178-8 9468-04
> > > >
> > > > AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c,
> 31789
> > > Hameln
> > > > AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska
> > > >
> > > >
> > > >
> > > >
> > >
>

Re: [DISCUSS][VOTE] Future of Log4j 1.x

[Tim Perry]

I propose that this vote should stay open longer than 72 hours given that we 
are coming up on New Years and many people who would wish to weigh in might be 
on vacation right now. 

Tim

> On Dec 29, 2021, at 2:29 PM, Matt Sicker  wrote:
> 
> Consistent contributors are frequently invited to be committers and later 
> PMC members. Having at least three people maintaining anything is an Apache 
> standard for maintaining vendor neutrality, ensuring a minimum number of 
> people can verify release candidates to address security issues or any other 
> releases.
> 
> —
> Matt Sicker
> 
>> On Dec 29, 2021, at 14:41, Vladimir Sitnikov  
>> wrote:
>> 
>> 
>>> 
>>> Log4j is owned by the Logging Services PMC. You cannot incubate it without
>> this PMC’s approval.
>> 
>> Exactly. As far as I understand, Logging pmc should accept patches and
>> release fixes or they should approve reincubating.
>> Of course, you can try rejecting patches and disapprove reincubation,
>> however, that won't hold water.
>> 
>> Unfortunately, I have not seen the response from the logging pmc regarding
>> approve/disapprove re-incubating. There's a pending question to Ron still.
>> 
>> I do not consider forks outside of the ASF.
>> 
>>> But I notice the one topic you did not respond to was the lack of
>> interested people other than yourself. Why is that?
>> 
>> I find the question irrelevant, and I find it has nothing to do with
>> accepting patches and releasing 1.2
>> I belive there were even people on incubator thread, so it is strange why
>> do you demand that I provide you with a list of rock-star 1.x maintainers.
>> 
>> 1) I can't guarantee I will be alive in February. Can you guarantee all the
>> logging pmc members will be alive then? I doubt so. So I find that
>> questions like "how can we be sure you will send patches" too intimate.
>> 
>> 2) I have already filed a patch for buildscripts. Whould you review it and
>> merge?
>> 
>> 3) Suppose I find a team (e.g 4-5 ASF fellows) who are willing to support
>> 1.2. What do you do then? Would you add all of them to the logging pmc?
>> I don't really see the point why do you ask, and at the same time I can't
>> guarantee the people I gather will be alive tomorrow. I can't guarantee
>> they will always have interest in 1.2
>> 
>> Vladimir

Re: [log4cxx] How to run the throughput test?

[Robert Middleton]

After taking a look at this, maybe the best option is to add the
throughput as a unit test so that we can set the path the same as the
other unit tests?  If it is not added as a unit test it won't be
run(which is good), but if we enable the option it will run.  You can
also run individual tests through visual studio, so that might solve
the problem.  Looking at the CMakeLists.txt, it doesn't actually do
anything with the path that it calculates, it's only building the exe.

I did try to add a custom target, but that does not let you set the
environment(which needs to be set for us to load the required DLLs
from the PATH).

-Robert Middleton

On Wed, Dec 29, 2021 at 5:27 PM Stephen Webb  wrote:
>
> That looks like a cmake issue - could you try cmake version 3.22?
>
> I am still using Visual Studio 2019 Community Edition.
>
> 
> Virus-free.
> www.avast.com
> 
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Thu, Dec 30, 2021 at 4:30 AM Robert Middleton 
> wrote:
>
> > Perhaps we need to add a custom target to CMake to make it runnable?
> > I think that would then hook into visual studio to make it easy to
> > run; I'll try to take a look at it tonight.
> >
> > The part of the CMakeLists.txt file that does that was copy
> > from one directory up, so it could be a directory level issue that I
> > missed.
> >
> > -Robert Middleton
> >
> > On Wed, Dec 29, 2021 at 7:15 AM Thorsten Schöning 
> > wrote:
> > >
> > > Hi everyone,
> > >
> > > I just tried to run the throughput test: Installed FMT using VCPKG,
> > > changed CMAKE to option that test ON and things built successfully.
> > > Though, running fails because log4cxx.dll can't be found. In theory
> > > CMAKE should already handle that using the following line:
> > >
> > > > set(LOG4CXX_DLL_DIR "$>;")
> > >
> > > Though, doesn't seem to work for my Windows and Visual Studio 2022.
> > > The actual path of that DLL is the following:
> > >
> > > > [...]\master\src\out\build\x64-Debug\src\main\cpp\log4cxx.dll
> > >
> > > Using PROCMON I can see that the test tries to load the file from the
> > > following LOG4CXX-specific directories instead:
> > >
> > > >
> > [...]\master\src\out\build\x64-Debug\src\test\cpp\throughput\log4cxx.dll
> > > > [...]\master\src\out\build\x64-Debug\src\test\cpp\helpers\log4cxx.dll
> > >
> > > Looking at the CMAKE file this somewhat makes sense, because at least
> > > the first line is the target directory of the throughput test.
> > >
> > > How is your setup? Do you manually copy the DLL or are executing the
> > > throughput test differently and Visual Studio makes a difference here?
> > >
> > > Mit freundlichen Grüßen
> > >
> > > Thorsten Schöning
> > >
> > > --
> > > AM-SoFT IT-Service - Bitstore Hameln GmbH
> > > Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und
> > TK
> > >
> > > E-Mail: thorsten.schoen...@am-soft.de
> > > Web:http://www.AM-SoFT.de/
> > >
> > > Tel:   05151-  9468- 0
> > > Tel:   05151-  9468-55
> > > Fax:   05151-  9468-88
> > > Mobil:  0178-8 9468-04
> > >
> > > AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789
> > Hameln
> > > AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska
> > >
> > >
> > >
> > >
> >

Re: [DISCUSS][VOTE] Future of Log4j 1.x

[Matt Sicker]

Consistent contributors are frequently invited to be committers and later PMC 
members. Having at least three people maintaining anything is an Apache 
standard for maintaining vendor neutrality, ensuring a minimum number of people 
can verify release candidates to address security issues or any other releases.

—
Matt Sicker

> On Dec 29, 2021, at 14:41, Vladimir Sitnikov  
> wrote:
> 
> 
>> 
>> Log4j is owned by the Logging Services PMC. You cannot incubate it without
> this PMC’s approval.
> 
> Exactly. As far as I understand, Logging pmc should accept patches and
> release fixes or they should approve reincubating.
> Of course, you can try rejecting patches and disapprove reincubation,
> however, that won't hold water.
> 
> Unfortunately, I have not seen the response from the logging pmc regarding
> approve/disapprove re-incubating. There's a pending question to Ron still.
> 
> I do not consider forks outside of the ASF.
> 
>> But I notice the one topic you did not respond to was the lack of
> interested people other than yourself. Why is that?
> 
> I find the question irrelevant, and I find it has nothing to do with
> accepting patches and releasing 1.2
> I belive there were even people on incubator thread, so it is strange why
> do you demand that I provide you with a list of rock-star 1.x maintainers.
> 
> 1) I can't guarantee I will be alive in February. Can you guarantee all the
> logging pmc members will be alive then? I doubt so. So I find that
> questions like "how can we be sure you will send patches" too intimate.
> 
> 2) I have already filed a patch for buildscripts. Whould you review it and
> merge?
> 
> 3) Suppose I find a team (e.g 4-5 ASF fellows) who are willing to support
> 1.2. What do you do then? Would you add all of them to the logging pmc?
> I don't really see the point why do you ask, and at the same time I can't
> guarantee the people I gather will be alive tomorrow. I can't guarantee
> they will always have interest in 1.2
> 
> Vladimir

Re: [log4cxx] How to run the throughput test?

[Stephen Webb]

That looks like a cmake issue - could you try cmake version 3.22?

I am still using Visual Studio 2019 Community Edition.


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Thu, Dec 30, 2021 at 4:30 AM Robert Middleton 
wrote:

> Perhaps we need to add a custom target to CMake to make it runnable?
> I think that would then hook into visual studio to make it easy to
> run; I'll try to take a look at it tonight.
>
> The part of the CMakeLists.txt file that does that was copy
> from one directory up, so it could be a directory level issue that I
> missed.
>
> -Robert Middleton
>
> On Wed, Dec 29, 2021 at 7:15 AM Thorsten Schöning 
> wrote:
> >
> > Hi everyone,
> >
> > I just tried to run the throughput test: Installed FMT using VCPKG,
> > changed CMAKE to option that test ON and things built successfully.
> > Though, running fails because log4cxx.dll can't be found. In theory
> > CMAKE should already handle that using the following line:
> >
> > > set(LOG4CXX_DLL_DIR "$>;")
> >
> > Though, doesn't seem to work for my Windows and Visual Studio 2022.
> > The actual path of that DLL is the following:
> >
> > > [...]\master\src\out\build\x64-Debug\src\main\cpp\log4cxx.dll
> >
> > Using PROCMON I can see that the test tries to load the file from the
> > following LOG4CXX-specific directories instead:
> >
> > >
> [...]\master\src\out\build\x64-Debug\src\test\cpp\throughput\log4cxx.dll
> > > [...]\master\src\out\build\x64-Debug\src\test\cpp\helpers\log4cxx.dll
> >
> > Looking at the CMAKE file this somewhat makes sense, because at least
> > the first line is the target directory of the throughput test.
> >
> > How is your setup? Do you manually copy the DLL or are executing the
> > throughput test differently and Visual Studio makes a difference here?
> >
> > Mit freundlichen Grüßen
> >
> > Thorsten Schöning
> >
> > --
> > AM-SoFT IT-Service - Bitstore Hameln GmbH
> > Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und
> TK
> >
> > E-Mail: thorsten.schoen...@am-soft.de
> > Web:http://www.AM-SoFT.de/
> >
> > Tel:   05151-  9468- 0
> > Tel:   05151-  9468-55
> > Fax:   05151-  9468-88
> > Mobil:  0178-8 9468-04
> >
> > AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789
> Hameln
> > AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska
> >
> >
> >
> >
>

Re: [DISCUSS][VOTE] Future of Log4j 1.x

[Vladimir Sitnikov]

>Log4j is owned by the Logging Services PMC. You cannot incubate it without
this PMC’s approval.

Exactly. As far as I understand, Logging pmc should accept patches and
release fixes or they should approve reincubating.
Of course, you can try rejecting patches and disapprove reincubation,
however, that won't hold water.

Unfortunately, I have not seen the response from the logging pmc regarding
approve/disapprove re-incubating. There's a pending question to Ron still.

I do not consider forks outside of the ASF.

>But I notice the one topic you did not respond to was the lack of
interested people other than yourself. Why is that?

I find the question irrelevant, and I find it has nothing to do with
accepting patches and releasing 1.2
I belive there were even people on incubator thread, so it is strange why
do you demand that I provide you with a list of rock-star 1.x maintainers.

1) I can't guarantee I will be alive in February. Can you guarantee all the
logging pmc members will be alive then? I doubt so. So I find that
questions like "how can we be sure you will send patches" too intimate.

2) I have already filed a patch for buildscripts. Whould you review it and
merge?

3) Suppose I find a team (e.g 4-5 ASF fellows) who are willing to support
1.2. What do you do then? Would you add all of them to the logging pmc?
I don't really see the point why do you ask, and at the same time I can't
guarantee the people I gather will be alive tomorrow. I can't guarantee
they will always have interest in 1.2

Vladimir

Re: [DISCUSS][VOTE] Future of Log4j 1.x

[Ralph Goers]

You are a member of 2 ASF projects yet you don’t understand how the ASF works?

Log4j is owned by the Logging Services PMC. You cannot incubate it without this 
PMC’s approval. 

You can certainly fork it outside the ASF but you cannot call it Log4j as the 
ASF owns the trademark. 
Sonatype would be unlikely to accept such a project with different maven 
coordinates that 
overlaps the log4j package naming as it would create a dependency mess. 

But I notice the one topic you did not respond to was the lack of interested 
people other than yourself. Why is that?

Ralph

> On Dec 29, 2021, at 1:05 PM, Vladimir Sitnikov  
> wrote:
> 
> If you are not interested in maintaining 1.x, please give it away (to
> another pmc or add pmc members) and that is it.
> 
> Even if you all vote for option 1, then I would just reincubate 1.x or find
> an alternative route to make 1.2.18, 1.2.19 and so on. So what is the point
> of this vote then? You can't really prevent 1.2.18, 1.2.19, ...
> 
> Vladimir

Re: [DISCUSS][VOTE] Future of Log4j 1.x

[Vladimir Sitnikov]

If you are not interested in maintaining 1.x, please give it away (to
another pmc or add pmc members) and that is it.

Even if you all vote for option 1, then I would just reincubate 1.x or find
an alternative route to make 1.2.18, 1.2.19 and so on. So what is the point
of this vote then? You can't really prevent 1.2.18, 1.2.19, ...

Vladimir

[DISCUSS][VOTE] Future of Log4j 1.x

[Ralph Goers]

What “People”. So far you are the only person who seems interested. Leo seemed 
interested at first but didn’t weigh in on the discussion thread. AFAIK that’s 
it. Two people does not make a community.

Furthermore, Log4j 1 was declared EOL 6 years ago and has been unsupported for 
9 years. It will remain EOL until the PMC says otherwise.

Ralph

> On Dec 29, 2021, at 12:46 PM, Vladimir Sitnikov  
> wrote:
> 
> -1 as it is invalid to say the project is "end of life" provided there are
> people willing to support it.
> 
> Vladimir

Re: [VOTE] Future of Log4j 1.x

[Vladimir Sitnikov]

-1 as it is invalid to say the project is "end of life" provided there are
people willing to support it.

Vladimir

[VOTE] Future of Log4j 1.x

[Christian Grobmeier]

Hello, 

as discussed in another thread, this is a vote about the future of log4j 1. 
This vote stays open for the usual 72h.
Options are explained below.

You can vote for:

 [ ] +1, Option 1
 [ ] +1, Option 2
 [ ] +/- 0, abstain
 [ ] -1 object against those options

Option 1: Create a README.md that publishes the projects EOL status and do 
nothing else.
Option 2: Create a README which says the project is EOL but allow the following 
work for 1.2.18 AND create a full release:
a.  Make the build work with a modern version of Maven.
b.  Fix the Java version bug.
c.  Fix CVE-2021-4104 (expanded to address all JNDI components)
d.  Fix CVE-2019-17571

Regards,
Christian
--
The Apache Software Foundation
V.P., Data Privacy

[ANNOUNCE} Apache Log4j 2.12.4 released for Java 7 (corrected links)

[Ralph Goers]

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

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

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

This release contains the changes noted below:

• Address CVE-2021-44832.

This release addresses CVE-2021-44832 for users still using Java 7.

The Log4j 2.12.4 API, as well as many core components, maintains binary 
compatibility with previous releases.

GA Release 2.12.4

Changes in this version include:

Fixed Bugs

• LOG4J2-3293: JdbcAppender now uses JndiManager to access JNDI 
resources. JNDI is only enabled when system property log4j2.enableJndiJdbc is 
set to true.

Apache Log4j 2.12.4 requires a minimum of Java 7 to build and run. Log4j 2.3 
was the last release that supported Java 6.

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

[ANNOUNCE] Apache Log4j 2.3.2 for Java 6 released

[Matt Sicker]

The Apache Log4j 2 team is pleased to announce the Log4j 2.3.2 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.2

Changes in this version include:


Fixed Bugs:
o LOG4J2-3293:  JDBC Appender should use JNDI Manager and JNDI access should be 
limited.
Backport fix for CVE-2021-44832. 
o LOG4J2-2819:  Add support for specifying an SSL configuration for 
SmtpAppender.
Backport fix for CVE-2020-9488 to allow SSL/TLS hostname verification. 



Apache Log4j 2.3.2 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:

http://logging.apache.org/log4j/2.x/
--
Matt Sicker

[ANNOUNCE] Apache Log4j 2.12.4 for Java 7 released

[Ralph Goers]

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

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

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

This release contains the changes noted below:

• Address CVE-2021-44832.

This release addresses CVE-2021-44832 for users still using Java 7.

The Log4j 2.12.4 API, as well as many core components, maintains binary 
compatibility with previous releases.

GA Release 2.12.4

Changes in this version include:

Fixed Bugs

• LOG4J2-3293: JdbcAppender now uses JndiManager to access JNDI 
resources. JNDI is only enabled when system property log4j2.enableJndiJdbc is 
set to true.

Apache Log4j 2.12.4 requires a minimum of Java 7 to build and run. Log4j 2.3 
was the last release that supported Java 6.

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/2.x/

Re: [VOTE] Release Log4j 2.3.2 for Java 6

[Matt Sicker]

Thanks! This vote is now closed with 6 +1 votes and one +0 vote.
--
Matt Sicker

> On Dec 29, 2021, at 12:46, Ron Grabowski  
> wrote:
> 
> +0 no concerns, I'm just not at a machine where I can verify
>On Wednesday, December 29, 2021, 01:40:50 PM EST, Matt Sicker 
>  wrote:  
> 
> I’m waiting to see if Ron or any other PMC members wanted to review this 
> before I close the vote and continue with the release.
> --
> Matt Sicker
> 
>> On Dec 29, 2021, at 11:42, Matt Sicker  wrote:
>> 
>> My +1
>> --
>> Matt Sicker
>> 
>>> On Dec 29, 2021, at 10:35, Carter Kozak >> > wrote:
>>> 
>>> +1
>>> 
>>> $ mvn -version
>>> Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
>>> Maven home: /opt/homebrew/Cellar/maven/3.8.4/libexec
>>> Java version: 1.8.0_312, vendor: Azul Systems, Inc., runtime: 
>>> /Users/ckozak/.tools/jdk/zulu8.58.0.13-ca-jdk8.0.312-macosx_aarch64/zulu-8.jdk/Contents/Home/jre
>>> Default locale: en_US, platform encoding: UTF-8
>>> OS name: "mac os x", version: "12.1", arch: "aarch64", family: "mac"
>>> 
>>> build/tests/rat look good
>>> 
>>> -ck
>>> 
>>> On Tue, Dec 28, 2021, at 20:59, Matt Sicker wrote:
 This is a vote to release Log4j 2.3.2, 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:
 
 Fixed Bugs
 
 Fixed Bugs:
 o LOG4J2-3293:  JDBC Appender should use JNDI Manager and JNDI access 
 should be limited.
 Backport fix for CVE-2021-44832.
 o LOG4J2-2819:  Add support for specifying an SSL configuration for 
 SmtpAppender.
 Backport fix for CVE-2020-9488 to allow SSL/TLS hostname 
 verification.
 
 Tag: 
 a)  for a new copy do "git clone 
 https://github.com/apache/logging-log4j2.git 
  
 >" and then "git checkout 
 tags/log4j-2.3.2-rc1”  or just "git clone -b log4j-2.3.2-rc1 
 https://github.com/apache/logging-log4j2.git 
  
 >"
 b) for an existing working copy to “git pull” and then “git checkout 
 tags/log4j-2.3.2-rc1”
 
 Web Site: [none published yet; need someone to stage a generated site]
 
 Maven Artifacts: 
 https://repository.apache.org/content/repositories/orgapachelogging-1081/ 
 
 
 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-1081/org/apache/logging/log4j/
  
 
 
 --
 Matt Sicker
>> 
> 

Re: [VOTE] Release Log4j 2.3.2 for Java 6

[Ron Grabowski]

 +0 no concerns, I'm just not at a machine where I can verify
On Wednesday, December 29, 2021, 01:40:50 PM EST, Matt Sicker 
 wrote:  
 
 I’m waiting to see if Ron or any other PMC members wanted to review this 
before I close the vote and continue with the release.
--
Matt Sicker

> On Dec 29, 2021, at 11:42, Matt Sicker  wrote:
> 
> My +1
> --
> Matt Sicker
> 
>> On Dec 29, 2021, at 10:35, Carter Kozak > > wrote:
>> 
>> +1
>> 
>> $ mvn -version
>> Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
>> Maven home: /opt/homebrew/Cellar/maven/3.8.4/libexec
>> Java version: 1.8.0_312, vendor: Azul Systems, Inc., runtime: 
>> /Users/ckozak/.tools/jdk/zulu8.58.0.13-ca-jdk8.0.312-macosx_aarch64/zulu-8.jdk/Contents/Home/jre
>> Default locale: en_US, platform encoding: UTF-8
>> OS name: "mac os x", version: "12.1", arch: "aarch64", family: "mac"
>> 
>> build/tests/rat look good
>> 
>> -ck
>> 
>> On Tue, Dec 28, 2021, at 20:59, Matt Sicker wrote:
>>> This is a vote to release Log4j 2.3.2, 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:
>>> 
>>> Fixed Bugs
>>> 
>>> Fixed Bugs:
>>> o LOG4J2-3293:  JDBC Appender should use JNDI Manager and JNDI access 
>>> should be limited.
>>>        Backport fix for CVE-2021-44832.
>>> o LOG4J2-2819:  Add support for specifying an SSL configuration for 
>>> SmtpAppender.
>>>        Backport fix for CVE-2020-9488 to allow SSL/TLS hostname 
>>>verification.
>>> 
>>> Tag: 
>>> a)  for a new copy do "git clone 
>>> https://github.com/apache/logging-log4j2.git 
>>>  
>>> >> >" and then "git checkout 
>>> tags/log4j-2.3.2-rc1”  or just "git clone -b log4j-2.3.2-rc1 
>>> https://github.com/apache/logging-log4j2.git 
>>>  
>>> >> >"
>>> b) for an existing working copy to “git pull” and then “git checkout 
>>> tags/log4j-2.3.2-rc1”
>>> 
>>> Web Site: [none published yet; need someone to stage a generated site]
>>> 
>>> Maven Artifacts: 
>>> https://repository.apache.org/content/repositories/orgapachelogging-1081/ 
>>> 
>>> 
>>> 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-1081/org/apache/logging/log4j/
>>>  
>>> 
>>> 
>>> --
>>> Matt Sicker
> 

  

Re: [VOTE] Release Log4j 2.3.2 for Java 6

[Matt Sicker]

I’m waiting to see if Ron or any other PMC members wanted to review this before 
I close the vote and continue with the release.
--
Matt Sicker

> On Dec 29, 2021, at 11:42, Matt Sicker  wrote:
> 
> My +1
> --
> Matt Sicker
> 
>> On Dec 29, 2021, at 10:35, Carter Kozak > > wrote:
>> 
>> +1
>> 
>> $ mvn -version
>> Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
>> Maven home: /opt/homebrew/Cellar/maven/3.8.4/libexec
>> Java version: 1.8.0_312, vendor: Azul Systems, Inc., runtime: 
>> /Users/ckozak/.tools/jdk/zulu8.58.0.13-ca-jdk8.0.312-macosx_aarch64/zulu-8.jdk/Contents/Home/jre
>> Default locale: en_US, platform encoding: UTF-8
>> OS name: "mac os x", version: "12.1", arch: "aarch64", family: "mac"
>> 
>> build/tests/rat look good
>> 
>> -ck
>> 
>> On Tue, Dec 28, 2021, at 20:59, Matt Sicker wrote:
>>> This is a vote to release Log4j 2.3.2, 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:
>>> 
>>> Fixed Bugs
>>> 
>>> Fixed Bugs:
>>> o LOG4J2-3293:  JDBC Appender should use JNDI Manager and JNDI access 
>>> should be limited.
>>>Backport fix for CVE-2021-44832.
>>> o LOG4J2-2819:  Add support for specifying an SSL configuration for 
>>> SmtpAppender.
>>>Backport fix for CVE-2020-9488 to allow SSL/TLS hostname 
>>> verification.
>>> 
>>> Tag: 
>>> a)  for a new copy do "git clone 
>>> https://github.com/apache/logging-log4j2.git 
>>>  
>>> >> >" and then "git checkout 
>>> tags/log4j-2.3.2-rc1”  or just "git clone -b log4j-2.3.2-rc1 
>>> https://github.com/apache/logging-log4j2.git 
>>>  
>>> >> >"
>>> b) for an existing working copy to “git pull” and then “git checkout 
>>> tags/log4j-2.3.2-rc1”
>>> 
>>> Web Site: [none published yet; need someone to stage a generated site]
>>> 
>>> Maven Artifacts: 
>>> https://repository.apache.org/content/repositories/orgapachelogging-1081/ 
>>> 
>>> 
>>> 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-1081/org/apache/logging/log4j/
>>>  
>>> 
>>> 
>>> --
>>> Matt Sicker
> 

Re: Maven published jars not matching jars downloaded from apache.org?

[Matt Sicker]

This is something that has been fixed (or will be fixed) in recent versions. 
This was caused by one of the Maven plugins in use outputting the current 
timestamp when it was run into the manifest file which got written for each 
invocation. New builds use reproducible timestamps instead generated when the 
tag is made.
--
Matt Sicker

> On Dec 29, 2021, at 11:57, Jason Pyeron  wrote:
> 
> We have noticed that many of the jars (almost all) when fetched by maven are 
> different from the ones packaged in the bin.zip which are different from the 
> bin.tar.gz?
> 
> 
> 
> This was observed while trying to identify multiple jars recently
> 
> 
> 
> e.g. log4j-core-2.14.0.jar
> 
> 063d95404bb4665a872d44a17710dab85bbb5fcf4eb22e777a6a137b50053235 from random 
> software package
> 
> 966886853b3b31fe100050d6294e921167ed510a3af6ac97dedc5f49b809a6d0 from 
> apache-log4j-2.14.0-bin.tar.gz
> 
> f04ee9c0ac417471d9127b5880b96c3147249f20674a8dbb88e9949d855382a8 from Maven
> 
> 68d793940c28ddff6670be703690dfdf9e77315970c42c4af40ca7261a8570fa from 
> apache-log4j-2.14.0-bin.zip
> 
> 
> 
> Thoughts?
> 
> 
> 
> Jason Pyeron  | Architect
> 
> PD Inc| Certified SBA 8(a)
> 
> 10 w 24th St  | Certified SBA HUBZone
> 
> Baltimore, MD | CAGE Code: 1WVR6
> 
> 
> 
> .mil:   jason.j.pyeron@mail.mil
> 
> .com:   jpye...@pdinc.us
> 
> tel : 202-741-9397
> 
> 
> 
> 
> 

Re: Published artifact hash files

[Gary Gregory]

That would be great.

Gary

On Wed, Dec 29, 2021, 12:54 Matt Sicker  wrote:

> The SHA files are generated via a Maven plugin that only outputs the hash,
> not the filename. Looks like we need to figure out how to configure that.
> --
> Matt Sicker
>
> > On Dec 29, 2021, at 02:53, Volkan Yazıcı  wrote:
> >
> > Certain hash files are not properly formatted (see below), can we (I?)
> fix
> > this?
> >
> > wget \
> >  --quiet \
> >  --execute robots=off \
> >  --timestamping \
> >  --cut-dirs=7 \
> >  --no-host-directories \
> >  --recursive \
> >  --page-requisites \
> >  --no-parent \
> >  --no-check-certificate \
> >  https://dist.apache.org/repos/dist/dev/logging/log4j/
> >
> > for sha_alg in 256 512; do
> >  find . -type f -name "*.sha$sha_alg" | while read sha_file; do
> >shasum --algorithm $sha_alg --check "$sha_file"
> >  done
> > done
> >
> > apache-log4j-api-scala-13.0-src.tar.gz: OK
> > apache-log4j-api-kotlin-1.2.0-bin.tar.gz: OK
> > apache-log4j-api-scala-13.0-src.zip: OK
> > apache-log4j-api-kotlin-1.2.0-bin.zip: OK
> > shasum: ./apache-log4j-2.12.4-src.tar.gz.sha256: no properly formatted
> SHA
> > checksum lines found
> > shasum: ./apache-log4j-2.12.4-bin.zip.sha256: no properly formatted SHA
> > checksum lines found
> > apache-log4j-api-kotlin-1.2.0-src.zip: OK
> > apache-log4j-api-kotlin-1.2.0-bin.tar.bz2: OK
> > apache-log4j-api-scala-13.0-bin.zip: OK
> > shasum: ./apache-log4j-2.3.2-src.zip.sha256: no properly formatted SHA
> > checksum lines found
> > shasum: ./apache-log4j-2.3.2-bin.tar.gz.sha256: no properly formatted SHA
> > checksum lines found
> > apache-log4j-api-kotlin-1.2.0-src.tar.bz2: OK
> > shasum: ./apache-log4j-2.12.4-bin.tar.gz.sha256: no properly formatted
> SHA
> > checksum lines found
> > shasum: ./apache-log4j-2.12.4-src.zip.sha256: no properly formatted SHA
> > checksum lines found
> > apache-log4j-api-scala-13.0-bin.tar.gz: OK
> > apache-log4j-api-kotlin-1.2.0-src.tar.gz: OK
> > shasum: ./apache-log4j-2.3.2-src.tar.gz.sha256: no properly formatted SHA
> > checksum lines found
> > shasum: ./apache-log4j-2.12.4-src.zip.sha512: no properly formatted SHA
> > checksum lines found
> > apache-log4j-api-scala-13.0-bin.zip: OK
> > apache-log4j-api-scala-13.0-bin.tar.gz: OK
> > apache-log4j-api-scala-13.0-src.tar.gz: OK
> > shasum: ./apache-log4j-2.12.4-bin.zip.sha512: no properly formatted SHA
> > checksum lines found
> > apache-log4j-api-kotlin-1.2.0-src.tar.gz: OK
> > apache-log4j-api-kotlin-1.2.0-src.zip: OK
> > shasum: ./apache-log4j-2.3.2-src.tar.gz.sha512: no properly formatted SHA
> > checksum lines found
> > shasum: ./apache-log4j-2.3.2-src.zip.sha512: no properly formatted SHA
> > checksum lines found
> > shasum: ./apache-log4j-2.12.4-src.tar.gz.sha512: no properly formatted
> SHA
> > checksum lines found
> > apache-log4j-api-kotlin-1.2.0-bin.tar.gz: OK
> > apache-log4j-api-kotlin-1.2.0-bin.tar.bz2: OK
> > apache-log4j-api-scala-13.0-src.zip: OK
> > apache-log4j-api-kotlin-1.2.0-src.tar.bz2: OK
> > shasum: ./apache-log4j-2.3.2-bin.tar.gz.sha512: no properly formatted SHA
> > checksum lines found
> > shasum: ./apache-log4j-2.12.4-bin.tar.gz.sha512: no properly formatted
> SHA
> > checksum lines found
> > shasum: ./apache-log4j-2.3.2-bin.zip.sha512: no properly formatted SHA
> > checksum lines found
> > apache-log4j-api-kotlin-1.2.0-bin.zip: OK
>
>

Re: rat:check at verify

[Matt Sicker]

Makes perfect sense to me to try to catch these problems as early as possible!
--
Matt Sicker

> On Dec 29, 2021, at 06:46, Gary Gregory  wrote:
> 
> +1
> 
> Gary
> 
> On Wed, Dec 29, 2021 at 4:25 AM Volkan Yazıcı  wrote:
> 
>> I suggest hooking apache-rat:check up to the verify stage in Maven. This
>> will make CI run that goal too. Objections?
>> 

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

[Matt Sicker]

Yes, not a bad idea. I’m going to cancel this vote to roll a fourth release 
candidate. I’ll also try to fix the site style bug on the components pages 
(might just need to remove the custom styling and use a default 
maven-site-plugin theme).
--
Matt Sicker

> On Dec 29, 2021, at 03:22, Gary Gregory  wrote:
> 
> I agree w Volkan here as well.
> 
> Gary
> 
> On Wed, Dec 29, 2021, 02:53 Volkan Yazıcı  wrote:
> 
>> Shall we cancel this, upgrade to 2.17.1, and revote?
>> 
>> On Tue, Dec 21, 2021 at 5:02 AM 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
>>> 
>>> 
>> 

Maven published jars not matching jars downloaded from apache.org?

[Jason Pyeron]

We have noticed that many of the jars (almost all) when fetched by maven are 
different from the ones packaged in the bin.zip which are different from the 
bin.tar.gz?

 

This was observed while trying to identify multiple jars recently

 

e.g. log4j-core-2.14.0.jar

063d95404bb4665a872d44a17710dab85bbb5fcf4eb22e777a6a137b50053235 from random 
software package

966886853b3b31fe100050d6294e921167ed510a3af6ac97dedc5f49b809a6d0 from 
apache-log4j-2.14.0-bin.tar.gz

f04ee9c0ac417471d9127b5880b96c3147249f20674a8dbb88e9949d855382a8 from Maven

68d793940c28ddff6670be703690dfdf9e77315970c42c4af40ca7261a8570fa from 
apache-log4j-2.14.0-bin.zip

 

Thoughts?

 

Jason Pyeron  | Architect

PD Inc| Certified SBA 8(a)

10 w 24th St  | Certified SBA HUBZone

Baltimore, MD | CAGE Code: 1WVR6

 

.mil:   jason.j.pyeron@mail.mil

.com:   jpye...@pdinc.us

tel : 202-741-9397

 

 

Re: [VOTE] Release Apache Log4j Scala API version 13.0-rc1

[Matt Sicker]

Yes, not a bad idea. I’m going to cancel this vote to roll a second release 
candidate.
--
Matt Sicker

> On Dec 29, 2021, at 03:21, Gary Gregory  wrote:
> 
> Volkan's right, better to lead by example and use our latest and safest
> 
> Gary
> 
> On Wed, Dec 29, 2021, 02:56 Volkan Yazıcı  wrote:
> 
>> Shall we cancel this, upgrade to 2.17.1, and revote?
>> 
>> On Thu, Dec 23, 2021 at 10:45 PM Matt Sicker  wrote:
>> 
>>> This is a vote to release Log4j Scala API 13.0. This release primarily
>>> adds support for Scala 3.
>>> 
>>> Please download, test, and cast your votes on the log4j developers list.
>>> [] +1, release the artifacts
>>> [] -1, don't release because...
>>> 
>>> The vote will remain open for 72 hours (or more if required). All votes
>>> are welcome and we encourage everyone to test the release, but only
>> Logging
>>> PMC votes are “officially” counted. As always, at least 3 +1 votes and
>> more
>>> positive than negative votes are required.
>>> 
>>> Changes in this release include:
>>> 
>>> New Features
>>> * LOG4J2-3184: Add support for Scala 3.0.
>>> 
>>> Tag:
>>> a)  for a new copy do "git clone
>>> https://github.com/apache/logging-log4j-scala.git <
>>> https://github.com/apache/logging-log4j-scala.git>" and then "git
>>> checkout tags/v13.0-rc1”  or just "git clone -b v13.0-rc1
>>> https://github.com/apache/logging-log4j-scala.git <
>>> https://github.com/apache/logging-log4j-scala.git>"
>>> b) for an existing working copy to “git pull” and then “git checkout
>>> tags/v13.0-rc1”
>>> 
>>> Web Site:
>>> https://logging.staged.apache.org/log4j/log4j-scala-13.0/index.html <
>>> https://logging.staged.apache.org/log4j/2.x/index.html>.
>>> 
>>> Maven Artifacts:
>>> 
>> https://repository.apache.org/content/repositories/orgapachelogging-1077/
>>> <
>> https://repository.apache.org/content/repositories/orgapachelogging-1065>
>>> 
>>> Distribution archives:
>>> https://dist.apache.org/repos/dist/dev/logging/log4j/scala/
>>> 
>>> 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-1077/org/apache/logging/log4j/
>>> <
>>> 
>> https://repository.apache.org/content/repositories/orgapachelogging-1065/org/apache/logging/log4j/
 
>>> 
>>> --
>>> Matt Sicker
>>> 
>>> 
>> 

Re: Published artifact hash files

[Matt Sicker]

The SHA files are generated via a Maven plugin that only outputs the hash, not 
the filename. Looks like we need to figure out how to configure that.
--
Matt Sicker

> On Dec 29, 2021, at 02:53, Volkan Yazıcı  wrote:
> 
> Certain hash files are not properly formatted (see below), can we (I?) fix
> this?
> 
> wget \
>  --quiet \
>  --execute robots=off \
>  --timestamping \
>  --cut-dirs=7 \
>  --no-host-directories \
>  --recursive \
>  --page-requisites \
>  --no-parent \
>  --no-check-certificate \
>  https://dist.apache.org/repos/dist/dev/logging/log4j/
> 
> for sha_alg in 256 512; do
>  find . -type f -name "*.sha$sha_alg" | while read sha_file; do
>shasum --algorithm $sha_alg --check "$sha_file"
>  done
> done
> 
> apache-log4j-api-scala-13.0-src.tar.gz: OK
> apache-log4j-api-kotlin-1.2.0-bin.tar.gz: OK
> apache-log4j-api-scala-13.0-src.zip: OK
> apache-log4j-api-kotlin-1.2.0-bin.zip: OK
> shasum: ./apache-log4j-2.12.4-src.tar.gz.sha256: no properly formatted SHA
> checksum lines found
> shasum: ./apache-log4j-2.12.4-bin.zip.sha256: no properly formatted SHA
> checksum lines found
> apache-log4j-api-kotlin-1.2.0-src.zip: OK
> apache-log4j-api-kotlin-1.2.0-bin.tar.bz2: OK
> apache-log4j-api-scala-13.0-bin.zip: OK
> shasum: ./apache-log4j-2.3.2-src.zip.sha256: no properly formatted SHA
> checksum lines found
> shasum: ./apache-log4j-2.3.2-bin.tar.gz.sha256: no properly formatted SHA
> checksum lines found
> apache-log4j-api-kotlin-1.2.0-src.tar.bz2: OK
> shasum: ./apache-log4j-2.12.4-bin.tar.gz.sha256: no properly formatted SHA
> checksum lines found
> shasum: ./apache-log4j-2.12.4-src.zip.sha256: no properly formatted SHA
> checksum lines found
> apache-log4j-api-scala-13.0-bin.tar.gz: OK
> apache-log4j-api-kotlin-1.2.0-src.tar.gz: OK
> shasum: ./apache-log4j-2.3.2-src.tar.gz.sha256: no properly formatted SHA
> checksum lines found
> shasum: ./apache-log4j-2.12.4-src.zip.sha512: no properly formatted SHA
> checksum lines found
> apache-log4j-api-scala-13.0-bin.zip: OK
> apache-log4j-api-scala-13.0-bin.tar.gz: OK
> apache-log4j-api-scala-13.0-src.tar.gz: OK
> shasum: ./apache-log4j-2.12.4-bin.zip.sha512: no properly formatted SHA
> checksum lines found
> apache-log4j-api-kotlin-1.2.0-src.tar.gz: OK
> apache-log4j-api-kotlin-1.2.0-src.zip: OK
> shasum: ./apache-log4j-2.3.2-src.tar.gz.sha512: no properly formatted SHA
> checksum lines found
> shasum: ./apache-log4j-2.3.2-src.zip.sha512: no properly formatted SHA
> checksum lines found
> shasum: ./apache-log4j-2.12.4-src.tar.gz.sha512: no properly formatted SHA
> checksum lines found
> apache-log4j-api-kotlin-1.2.0-bin.tar.gz: OK
> apache-log4j-api-kotlin-1.2.0-bin.tar.bz2: OK
> apache-log4j-api-scala-13.0-src.zip: OK
> apache-log4j-api-kotlin-1.2.0-src.tar.bz2: OK
> shasum: ./apache-log4j-2.3.2-bin.tar.gz.sha512: no properly formatted SHA
> checksum lines found
> shasum: ./apache-log4j-2.12.4-bin.tar.gz.sha512: no properly formatted SHA
> checksum lines found
> shasum: ./apache-log4j-2.3.2-bin.zip.sha512: no properly formatted SHA
> checksum lines found
> apache-log4j-api-kotlin-1.2.0-bin.zip: OK

Re: [VOTE] Release Log4j 2.3.2 for Java 6

[Matt Sicker]

My +1
--
Matt Sicker

> On Dec 29, 2021, at 10:35, Carter Kozak  wrote:
> 
> +1
> 
> $ mvn -version
> Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
> Maven home: /opt/homebrew/Cellar/maven/3.8.4/libexec
> Java version: 1.8.0_312, vendor: Azul Systems, Inc., runtime: 
> /Users/ckozak/.tools/jdk/zulu8.58.0.13-ca-jdk8.0.312-macosx_aarch64/zulu-8.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "12.1", arch: "aarch64", family: "mac"
> 
> build/tests/rat look good
> 
> -ck
> 
> On Tue, Dec 28, 2021, at 20:59, Matt Sicker wrote:
>> This is a vote to release Log4j 2.3.2, 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:
>> 
>> Fixed Bugs
>> 
>> Fixed Bugs:
>> o LOG4J2-3293:  JDBC Appender should use JNDI Manager and JNDI access should 
>> be limited.
>>Backport fix for CVE-2021-44832.
>> o LOG4J2-2819:  Add support for specifying an SSL configuration for 
>> SmtpAppender.
>>Backport fix for CVE-2020-9488 to allow SSL/TLS hostname verification.
>> 
>> Tag: 
>> a)  for a new copy do "git clone 
>> https://github.com/apache/logging-log4j2.git 
>>  
>> > >" and then "git checkout 
>> tags/log4j-2.3.2-rc1”  or just "git clone -b log4j-2.3.2-rc1 
>> https://github.com/apache/logging-log4j2.git 
>>  
>> > >"
>> b) for an existing working copy to “git pull” and then “git checkout 
>> tags/log4j-2.3.2-rc1”
>> 
>> Web Site: [none published yet; need someone to stage a generated site]
>> 
>> Maven Artifacts: 
>> https://repository.apache.org/content/repositories/orgapachelogging-1081/ 
>> 
>> 
>> 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-1081/org/apache/logging/log4j/
>>  
>> 
>> 
>> --
>> Matt Sicker

[RESuLT][VOTE] Release Log4j 2.12.4-rc1 for Java 7

[Ralph Goers]

This vote passes with +1 votes from Gary Gregory, Ron Grabowsky, Remko Popma, 
Volkan Yazici, Carter Kozak, Matt Sicker and Ralph Goers. There were no other 
votes.

I will continue with the release process.

Ralph

Re: [VOTE] Release Log4j 2.12.4-rc1 for Java 7

[Ralph Goers]

My +1

Ralph

> On Dec 29, 2021, at 10:33 AM, Matt Sicker  wrote:
> 
> +1
> 
> Checked build, archives, sigs.
> --
> Matt Sicker
> 
>> On Dec 29, 2021, at 10:49, Carter Kozak  wrote:
>> 
>> +1
>> 
>> rat and build look good, usual issues with mongo tests on m1
>> 
>> $mvn --version
>> Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
>> Maven home: /opt/homebrew/Cellar/maven/3.8.4/libexec
>> Java version: 1.8.0_312, vendor: Azul Systems, Inc., runtime: 
>> /Users/ckozak/.tools/jdk/zulu8.58.0.13-ca-jdk8.0.312-macosx_aarch64/zulu-8.jdk/Contents/Home/jre
>> Default locale: en_US, platform encoding: UTF-8
>> OS name: "mac os x", version: "12.1", arch: "aarch64", family: "mac"
>> 
>> -ck
>> 
>> On Wed, Dec 29, 2021, at 02:31, Volkan Yazıcı wrote:
>>> +1
>>> 
>>> commits OK
>>> sigs OK
>>> hashes OK
>>> `./mvnw clean verify apache-rat:check` OK on
>>> 
>>> $ java -version
>>> openjdk version "1.8.0_312"
>>> OpenJDK Runtime Environment (Zulu 8.58.0.13-CA-linux64) (build
>>> 1.8.0_312-b07)
>>> OpenJDK 64-Bit Server VM (Zulu 8.58.0.13-CA-linux64) (build 25.312-b07,
>>> mixed mode)
>>> 
>>> $ uname -a
>>> Linux tahta 5.11.0-43-generic #47~20.04.2-Ubuntu SMP Mon Dec 13 11:06:56
>>> UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
>>> 
>>> 
>>> On Wed, Dec 29, 2021 at 12:03 AM Ralph Goers 
>>> wrote:
>>> 
 This is a vote to release Log4j 2.12.4, 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-3293: JdbcAppender now uses JndiManager to access JNDI
 resources. JNDI is only enabled when system property log4j2.enableJndiJdbc
 is set to true.
 
 Tag:
 a)  for a new copy do "git clone
 https://github.com/apache/logging-log4j2.git; and then "git checkout
 tags/log4j-2.12.4-rc1”  or just "git clone -b log4j-2.12.4-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.4-rc1”
 
 Web Site:  https://logging.staged.apache.org/log4j/log4j-2.12.4/index.html
 
 Maven Artifacts:
 https://repository.apache.org/content/repositories/orgapachelogging-1080
 
 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-1080/org/apache/logging/log4j/
 .
 
 Ralph
>>> 
> 
> 

Re: [VOTE] Release Log4j 2.12.4-rc1 for Java 7

[Matt Sicker]

+1

Checked build, archives, sigs.
--
Matt Sicker

> On Dec 29, 2021, at 10:49, Carter Kozak  wrote:
> 
> +1
> 
> rat and build look good, usual issues with mongo tests on m1
> 
> $mvn --version
> Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
> Maven home: /opt/homebrew/Cellar/maven/3.8.4/libexec
> Java version: 1.8.0_312, vendor: Azul Systems, Inc., runtime: 
> /Users/ckozak/.tools/jdk/zulu8.58.0.13-ca-jdk8.0.312-macosx_aarch64/zulu-8.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "12.1", arch: "aarch64", family: "mac"
> 
> -ck
> 
> On Wed, Dec 29, 2021, at 02:31, Volkan Yazıcı wrote:
>> +1
>> 
>> commits OK
>> sigs OK
>> hashes OK
>> `./mvnw clean verify apache-rat:check` OK on
>> 
>> $ java -version
>> openjdk version "1.8.0_312"
>> OpenJDK Runtime Environment (Zulu 8.58.0.13-CA-linux64) (build
>> 1.8.0_312-b07)
>> OpenJDK 64-Bit Server VM (Zulu 8.58.0.13-CA-linux64) (build 25.312-b07,
>> mixed mode)
>> 
>> $ uname -a
>> Linux tahta 5.11.0-43-generic #47~20.04.2-Ubuntu SMP Mon Dec 13 11:06:56
>> UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
>> 
>> 
>> On Wed, Dec 29, 2021 at 12:03 AM Ralph Goers 
>> wrote:
>> 
>>> This is a vote to release Log4j 2.12.4, 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-3293: JdbcAppender now uses JndiManager to access JNDI
>>> resources. JNDI is only enabled when system property log4j2.enableJndiJdbc
>>> is set to true.
>>> 
>>> Tag:
>>> a)  for a new copy do "git clone
>>> https://github.com/apache/logging-log4j2.git; and then "git checkout
>>> tags/log4j-2.12.4-rc1”  or just "git clone -b log4j-2.12.4-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.4-rc1”
>>> 
>>> Web Site:  https://logging.staged.apache.org/log4j/log4j-2.12.4/index.html
>>> 
>>> Maven Artifacts:
>>> https://repository.apache.org/content/repositories/orgapachelogging-1080
>>> 
>>> 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-1080/org/apache/logging/log4j/
>>> .
>>> 
>>> Ralph
>> 

Re: [log4cxx] How to run the throughput test?

[Robert Middleton]

Perhaps we need to add a custom target to CMake to make it runnable?
I think that would then hook into visual studio to make it easy to
run; I'll try to take a look at it tonight.

The part of the CMakeLists.txt file that does that was copy
from one directory up, so it could be a directory level issue that I
missed.

-Robert Middleton

On Wed, Dec 29, 2021 at 7:15 AM Thorsten Schöning  wrote:
>
> Hi everyone,
>
> I just tried to run the throughput test: Installed FMT using VCPKG,
> changed CMAKE to option that test ON and things built successfully.
> Though, running fails because log4cxx.dll can't be found. In theory
> CMAKE should already handle that using the following line:
>
> > set(LOG4CXX_DLL_DIR "$>;")
>
> Though, doesn't seem to work for my Windows and Visual Studio 2022.
> The actual path of that DLL is the following:
>
> > [...]\master\src\out\build\x64-Debug\src\main\cpp\log4cxx.dll
>
> Using PROCMON I can see that the test tries to load the file from the
> following LOG4CXX-specific directories instead:
>
> > [...]\master\src\out\build\x64-Debug\src\test\cpp\throughput\log4cxx.dll
> > [...]\master\src\out\build\x64-Debug\src\test\cpp\helpers\log4cxx.dll
>
> Looking at the CMAKE file this somewhat makes sense, because at least
> the first line is the target directory of the throughput test.
>
> How is your setup? Do you manually copy the DLL or are executing the
> throughput test differently and Visual Studio makes a difference here?
>
> Mit freundlichen Grüßen
>
> Thorsten Schöning
>
> --
> AM-SoFT IT-Service - Bitstore Hameln GmbH
> Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK
>
> E-Mail: thorsten.schoen...@am-soft.de
> Web:http://www.AM-SoFT.de/
>
> Tel:   05151-  9468- 0
> Tel:   05151-  9468-55
> Fax:   05151-  9468-88
> Mobil:  0178-8 9468-04
>
> AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska
>
>
>
>

Re: [VOTE] Release Log4j 2.12.4-rc1 for Java 7

[Carter Kozak]

+1

rat and build look good, usual issues with mongo tests on m1

$mvn --version
Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /opt/homebrew/Cellar/maven/3.8.4/libexec
Java version: 1.8.0_312, vendor: Azul Systems, Inc., runtime: 
/Users/ckozak/.tools/jdk/zulu8.58.0.13-ca-jdk8.0.312-macosx_aarch64/zulu-8.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "12.1", arch: "aarch64", family: "mac"

-ck

On Wed, Dec 29, 2021, at 02:31, Volkan Yazıcı wrote:
> +1
> 
> commits OK
> sigs OK
> hashes OK
> `./mvnw clean verify apache-rat:check` OK on
> 
> $ java -version
> openjdk version "1.8.0_312"
> OpenJDK Runtime Environment (Zulu 8.58.0.13-CA-linux64) (build
> 1.8.0_312-b07)
> OpenJDK 64-Bit Server VM (Zulu 8.58.0.13-CA-linux64) (build 25.312-b07,
> mixed mode)
> 
> $ uname -a
> Linux tahta 5.11.0-43-generic #47~20.04.2-Ubuntu SMP Mon Dec 13 11:06:56
> UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
> 
> 
> On Wed, Dec 29, 2021 at 12:03 AM Ralph Goers 
> wrote:
> 
> > This is a vote to release Log4j 2.12.4, 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-3293: JdbcAppender now uses JndiManager to access JNDI
> > resources. JNDI is only enabled when system property log4j2.enableJndiJdbc
> > is set to true.
> >
> > Tag:
> > a)  for a new copy do "git clone
> > https://github.com/apache/logging-log4j2.git; and then "git checkout
> > tags/log4j-2.12.4-rc1”  or just "git clone -b log4j-2.12.4-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.4-rc1”
> >
> > Web Site:  https://logging.staged.apache.org/log4j/log4j-2.12.4/index.html
> >
> > Maven Artifacts:
> > https://repository.apache.org/content/repositories/orgapachelogging-1080
> >
> > 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-1080/org/apache/logging/log4j/
> > .
> >
> > Ralph
> 

Re: [VOTE] Release Log4j 2.3.2 for Java 6

[Carter Kozak]

+1

$ mvn -version
Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /opt/homebrew/Cellar/maven/3.8.4/libexec
Java version: 1.8.0_312, vendor: Azul Systems, Inc., runtime: 
/Users/ckozak/.tools/jdk/zulu8.58.0.13-ca-jdk8.0.312-macosx_aarch64/zulu-8.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "12.1", arch: "aarch64", family: "mac"

build/tests/rat look good

-ck

On Tue, Dec 28, 2021, at 20:59, Matt Sicker wrote:
> This is a vote to release Log4j 2.3.2, 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:
> 
> Fixed Bugs
> 
> Fixed Bugs:
> o LOG4J2-3293:  JDBC Appender should use JNDI Manager and JNDI access should 
> be limited.
> Backport fix for CVE-2021-44832.
> o LOG4J2-2819:  Add support for specifying an SSL configuration for 
> SmtpAppender.
> Backport fix for CVE-2020-9488 to allow SSL/TLS hostname verification.
> 
> Tag: 
> a)  for a new copy do "git clone https://github.com/apache/logging-log4j2.git 
> " and then "git checkout 
> tags/log4j-2.3.2-rc1”  or just "git clone -b log4j-2.3.2-rc1 
> https://github.com/apache/logging-log4j2.git 
> "
> b) for an existing working copy to “git pull” and then “git checkout 
> tags/log4j-2.3.2-rc1”
> 
> Web Site: [none published yet; need someone to stage a generated site]
> 
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachelogging-1081/
> 
> 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-1081/org/apache/logging/log4j/
> 
> --
> Matt Sicker
> 
> 

Re: rat:check at verify

[Gary Gregory]

+1

Gary

On Wed, Dec 29, 2021 at 4:25 AM Volkan Yazıcı  wrote:

> I suggest hooking apache-rat:check up to the verify stage in Maven. This
> will make CI run that goal too. Objections?
>

[log4cxx] How to run the throughput test?

[Thorsten Schöning]

Hi everyone,

I just tried to run the throughput test: Installed FMT using VCPKG,
changed CMAKE to option that test ON and things built successfully.
Though, running fails because log4cxx.dll can't be found. In theory
CMAKE should already handle that using the following line:

> set(LOG4CXX_DLL_DIR "$>;")

Though, doesn't seem to work for my Windows and Visual Studio 2022.
The actual path of that DLL is the following:

> [...]\master\src\out\build\x64-Debug\src\main\cpp\log4cxx.dll

Using PROCMON I can see that the test tries to load the file from the
following LOG4CXX-specific directories instead:

> [...]\master\src\out\build\x64-Debug\src\test\cpp\throughput\log4cxx.dll
> [...]\master\src\out\build\x64-Debug\src\test\cpp\helpers\log4cxx.dll

Looking at the CMAKE file this somewhat makes sense, because at least
the first line is the target directory of the throughput test.

How is your setup? Do you manually copy the DLL or are executing the
throughput test differently and Visual Studio makes a difference here?

Mit freundlichen Grüßen

Thorsten Schöning

-- 
AM-SoFT IT-Service - Bitstore Hameln GmbH
Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK

E-Mail: thorsten.schoen...@am-soft.de
Web:http://www.AM-SoFT.de/

Tel:   05151-  9468- 0
Tel:   05151-  9468-55
Fax:   05151-  9468-88
Mobil:  0178-8 9468-04

AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska

rat:check at verify

[Volkan Yazıcı]

I suggest hooking apache-rat:check up to the verify stage in Maven. This
will make CI run that goal too. Objections?

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

[Gary Gregory]

I agree w Volkan here as well.

Gary

On Wed, Dec 29, 2021, 02:53 Volkan Yazıcı  wrote:

> Shall we cancel this, upgrade to 2.17.1, and revote?
>
> On Tue, Dec 21, 2021 at 5:02 AM 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 Scala API version 13.0-rc1

[Gary Gregory]

Volkan's right, better to lead by example and use our latest and safest

Gary

On Wed, Dec 29, 2021, 02:56 Volkan Yazıcı  wrote:

> Shall we cancel this, upgrade to 2.17.1, and revote?
>
> On Thu, Dec 23, 2021 at 10:45 PM Matt Sicker  wrote:
>
> > This is a vote to release Log4j Scala API 13.0. This release primarily
> > adds support for Scala 3.
> >
> > Please download, test, and cast your votes on the log4j developers list.
> > [] +1, release the artifacts
> > [] -1, don't release because...
> >
> > The vote will remain open for 72 hours (or more if required). All votes
> > are welcome and we encourage everyone to test the release, but only
> Logging
> > PMC votes are “officially” counted. As always, at least 3 +1 votes and
> more
> > positive than negative votes are required.
> >
> > Changes in this release include:
> >
> > New Features
> > * LOG4J2-3184: Add support for Scala 3.0.
> >
> > Tag:
> > a)  for a new copy do "git clone
> > https://github.com/apache/logging-log4j-scala.git <
> > https://github.com/apache/logging-log4j-scala.git>" and then "git
> > checkout tags/v13.0-rc1”  or just "git clone -b v13.0-rc1
> > https://github.com/apache/logging-log4j-scala.git <
> > https://github.com/apache/logging-log4j-scala.git>"
> > b) for an existing working copy to “git pull” and then “git checkout
> > tags/v13.0-rc1”
> >
> > Web Site:
> > https://logging.staged.apache.org/log4j/log4j-scala-13.0/index.html <
> > https://logging.staged.apache.org/log4j/2.x/index.html>.
> >
> > Maven Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachelogging-1077/
> > <
> https://repository.apache.org/content/repositories/orgapachelogging-1065>
> >
> > Distribution archives:
> > https://dist.apache.org/repos/dist/dev/logging/log4j/scala/
> >
> > 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-1077/org/apache/logging/log4j/
> > <
> >
> https://repository.apache.org/content/repositories/orgapachelogging-1065/org/apache/logging/log4j/
> > >
> >
> > --
> > Matt Sicker
> >
> >
>

Re: [DISCUSS] The future of Log4j 1.x

[Christian Grobmeier]

I am going to set up a vote for option 1 and 4. I think we have this thread 
open for a long time already and don't  expect many other responses

--
The Apache Software Foundation
V.P., Data Privacy

On Wed, Dec 29, 2021, at 07:55, Volkan Yazıcı wrote:
> Agreed with all points of Carter.
>
> It is either 1 or 4.
> Anything more than 4 (including 5) is a hard no from me.
>
> On Fri, Dec 24, 2021 at 6:00 PM Carter Kozak  wrote:
>
>> I would agree directionally with option 1 or option 4.
>>
>> Making changes without pushing binary artifacts to maven central (options
>> 2 and 3) is unlikely to do much good for the types of projects which still
>> use log4j1. Option 5 is a hard no from me, my time is already too
>> constrained, there are better options, and the architecture limits
>> substantive improvements.
>>
>> -ck
>>
>> On Fri, Dec 24, 2021, at 11:47, Ralph Goers wrote:
>> > As we all know Log4j 1.x reached end of life in August 2015. Log4j
>> 1.2.17 was released on May 26, 2012. The last commit was to update the
>> > web site 7 years ago. The changes.xml file shows there were commits up
>> to sometime in 2012, all of which were performed by Gary Gregory
>> > and Christian Grobmeier who ironically both voted no to opening the repo
>> back up.
>> >
>> > The point of this history is to point out that the project essentially
>> died in 2012. We simply acknowledged it in 2015.
>> >
>> > So now we have voted to open the repo. The question then becomes what to
>> do next and going forward. I see several options:
>> >
>> > 1. Create a README.md that publishes the projects EOL status and do
>> nothing else.
>> > 2. Create a README.md that says the project is EOL and no further big
>> fixes or enhancements will be made but 1.2.18 was a special
>> > circumstance. Perform ONLY the following work for 1.2.18:
>> > a.  Make the build work with a modern version of Maven.
>> > b.  Fix the Java version bug.
>> > c.  Fix CVE-2021-4104 (expanded to address all JNDI components)
>> > d.  Fix CVE-2019-17571
>> > The expectation is that the above would address the actual issues
>> and not just remove classes.
>> > Do NOT perform a release of any kind.
>> > 3. Option 2 but only perform a source release.
>> > 4. Option 2 but perform a full release.
>> > 5. Option 4 but allow development to continue, including bug fixes and
>> enhancements.
>> >
>> > I personally can see valid reasons to do any of the above.  I have my
>> own opinion on this but I will post that in a reply to this discussion
>> kickoff.
>> >
>> > If you have other proposals feel free to state them.
>> >
>> > This discussion will be followed up by a vote thread if necessary.
>> >
>> > Ralph
>> >
>> >
>> >
>>

Published artifact hash files

[Volkan Yazıcı]

Certain hash files are not properly formatted (see below), can we (I?) fix
this?

wget \
  --quiet \
  --execute robots=off \
  --timestamping \
  --cut-dirs=7 \
  --no-host-directories \
  --recursive \
  --page-requisites \
  --no-parent \
  --no-check-certificate \
  https://dist.apache.org/repos/dist/dev/logging/log4j/

for sha_alg in 256 512; do
  find . -type f -name "*.sha$sha_alg" | while read sha_file; do
shasum --algorithm $sha_alg --check "$sha_file"
  done
done

apache-log4j-api-scala-13.0-src.tar.gz: OK
apache-log4j-api-kotlin-1.2.0-bin.tar.gz: OK
apache-log4j-api-scala-13.0-src.zip: OK
apache-log4j-api-kotlin-1.2.0-bin.zip: OK
shasum: ./apache-log4j-2.12.4-src.tar.gz.sha256: no properly formatted SHA
checksum lines found
shasum: ./apache-log4j-2.12.4-bin.zip.sha256: no properly formatted SHA
checksum lines found
apache-log4j-api-kotlin-1.2.0-src.zip: OK
apache-log4j-api-kotlin-1.2.0-bin.tar.bz2: OK
apache-log4j-api-scala-13.0-bin.zip: OK
shasum: ./apache-log4j-2.3.2-src.zip.sha256: no properly formatted SHA
checksum lines found
shasum: ./apache-log4j-2.3.2-bin.tar.gz.sha256: no properly formatted SHA
checksum lines found
apache-log4j-api-kotlin-1.2.0-src.tar.bz2: OK
shasum: ./apache-log4j-2.12.4-bin.tar.gz.sha256: no properly formatted SHA
checksum lines found
shasum: ./apache-log4j-2.12.4-src.zip.sha256: no properly formatted SHA
checksum lines found
apache-log4j-api-scala-13.0-bin.tar.gz: OK
apache-log4j-api-kotlin-1.2.0-src.tar.gz: OK
shasum: ./apache-log4j-2.3.2-src.tar.gz.sha256: no properly formatted SHA
checksum lines found
shasum: ./apache-log4j-2.12.4-src.zip.sha512: no properly formatted SHA
checksum lines found
apache-log4j-api-scala-13.0-bin.zip: OK
apache-log4j-api-scala-13.0-bin.tar.gz: OK
apache-log4j-api-scala-13.0-src.tar.gz: OK
shasum: ./apache-log4j-2.12.4-bin.zip.sha512: no properly formatted SHA
checksum lines found
apache-log4j-api-kotlin-1.2.0-src.tar.gz: OK
apache-log4j-api-kotlin-1.2.0-src.zip: OK
shasum: ./apache-log4j-2.3.2-src.tar.gz.sha512: no properly formatted SHA
checksum lines found
shasum: ./apache-log4j-2.3.2-src.zip.sha512: no properly formatted SHA
checksum lines found
shasum: ./apache-log4j-2.12.4-src.tar.gz.sha512: no properly formatted SHA
checksum lines found
apache-log4j-api-kotlin-1.2.0-bin.tar.gz: OK
apache-log4j-api-kotlin-1.2.0-bin.tar.bz2: OK
apache-log4j-api-scala-13.0-src.zip: OK
apache-log4j-api-kotlin-1.2.0-src.tar.bz2: OK
shasum: ./apache-log4j-2.3.2-bin.tar.gz.sha512: no properly formatted SHA
checksum lines found
shasum: ./apache-log4j-2.12.4-bin.tar.gz.sha512: no properly formatted SHA
checksum lines found
shasum: ./apache-log4j-2.3.2-bin.zip.sha512: no properly formatted SHA
checksum lines found
apache-log4j-api-kotlin-1.2.0-bin.zip: OK