You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Ralph Goers <ra...@dslextreme.com> on 2022/05/20 16:06:00 UTC
Log4j 2.18.0
I am working through the last few issues I want to resolve for 2.18.0. I’d like to hope I can have them done today but I might not. I will be traveling tomorrow through Wed, May 25 to visit friends and family. While it is possible I might be able to do the release then, it is unlikely. So right now my plan is to start the process next Wednesday evening MST.
Ralph
Re: Log4j 2.18.0
Posted by Gary Gregory <ga...@gmail.com>.
Sounds good to me. I'll see if I have anything pending over the weekend but
if I do it is not critical.
Gary
On Fri, May 20, 2022, 12:06 Ralph Goers <ra...@dslextreme.com> wrote:
> I am working through the last few issues I want to resolve for 2.18.0.
> I’d like to hope I can have them done today but I might not. I will be
> traveling tomorrow through Wed, May 25 to visit friends and family. While
> it is possible I might be able to do the release then, it is unlikely. So
> right now my plan is to start the process next Wednesday evening MST.
>
> Ralph
Re: Log4j 2.18.0
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Ralph,
On Mon, 30 May 2022 at 09:11, Ralph Goers <ra...@dslextreme.com>
wrote:
> I ran it multiple times in my Windows VM and it failed each time. I am not
> going
> to hunt down what directories I need to be deleting. The test needs to do
> that.
>
I perfectly understand your POV. Actually looking at the test's code, it
has some methods to clean up after himself, but they were not working. It
should work now.
I don't entirely understand why `JdbcAppenderColumnMappingLiteralTest` uses
a file-backed DB, while the remaining tests use a memory-backed DB, but I
left it the way it is.
Piotr
Re: Log4j 2.18.0
Posted by Ralph Goers <ra...@dslextreme.com>.
I ran it multiple times in my Windows VM and it failed each time. I am not going
to hunt down what directories I need to be deleting. The test needs to do that.
Since H2 is only used for testing I don’t consider it a big deal. The link you
provided clearly shows it is a test dependency so almost no-one will care.
But if you want to fix the failing test I am OK with that.
I should point out though that this is the poster boy for why we need to break up
Log4j into multiple repos. Or rather, LOG4J2-3428 makes it clear why. It shows
36 dependencies being upgraded since 2.17.2 was released. I am betting most
of them are test dependencies but still, with that many dependencies updated the
likelihood of problems goes way up.
Ralph
> On May 29, 2022, at 11:54 PM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>
> Hi Ralph,
>
> On Mon, 30 May 2022 at 00:26, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> FWIW, the h2 upgrade broke the build. I am in the process of reverting the
>> version change.
>>
>> Ralph
>>
>
> I would really like the H2 upgrade to be included in 2.18.0, so that pages
> like this:
>
> https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core/2.17.2
>
> don't have any red notices.
>
> As I explained in another e-mail, the failure of the test is due to the
> fact that the test leaves garbage in the temporary directory. When you
> switch from H2 1.x to H2 2.x the test tries to load the leftovers of the
> previous execution of the test and fails.
>
> After 2.18.0 I can find all tests to pinpoint those that leave files in the
> filesystem. Since Surefire runs each test in a separate JVM, I believe that
> by correcting the misbehaving tests, we will be able to run tests in
> parallel.
>
> Piotr
Re: Log4j 2.18.0
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Ralph,
On Mon, 30 May 2022 at 00:26, Ralph Goers <ra...@dslextreme.com>
wrote:
> FWIW, the h2 upgrade broke the build. I am in the process of reverting the
> version change.
>
> Ralph
>
I would really like the H2 upgrade to be included in 2.18.0, so that pages
like this:
https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core/2.17.2
don't have any red notices.
As I explained in another e-mail, the failure of the test is due to the
fact that the test leaves garbage in the temporary directory. When you
switch from H2 1.x to H2 2.x the test tries to load the leftovers of the
previous execution of the test and fails.
After 2.18.0 I can find all tests to pinpoint those that leave files in the
filesystem. Since Surefire runs each test in a separate JVM, I believe that
by correcting the misbehaving tests, we will be able to run tests in
parallel.
Piotr
Re: Log4j 2.18.0
Posted by Ralph Goers <ra...@dslextreme.com>.
FWIW, the h2 upgrade broke the build. I am in the process of reverting the version change.
Ralph
> On May 25, 2022, at 10:30 PM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>
> Hi Ralph,
>
> On Thu, 26 May 2022 at 06:47, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> If you are confident in it then feel free to commit it. Remember, we still
>> fundamentally
>> operate using CTR so even if you are using PRs you don’t necessarily have
>> to wait
>> for approvals. That said, I glanced at the PR and nothing jumped out at
>> me, but I
>> didn’t do an exhaustive review.
>>
>
> I feel confident it will not break anything else, but I prefer to keep our
> scorecard high, unless we don't have time to review it.
>
> Piotr
Re: Log4j 2.18.0
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Ralph,
On Thu, 26 May 2022 at 06:47, Ralph Goers <ra...@dslextreme.com>
wrote:
> If you are confident in it then feel free to commit it. Remember, we still
> fundamentally
> operate using CTR so even if you are using PRs you don’t necessarily have
> to wait
> for approvals. That said, I glanced at the PR and nothing jumped out at
> me, but I
> didn’t do an exhaustive review.
>
I feel confident it will not break anything else, but I prefer to keep our
scorecard high, unless we don't have time to review it.
Piotr
Re: Log4j 2.18.0
Posted by Ralph Goers <ra...@dslextreme.com>.
> On May 25, 2022, at 9:53 AM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>
> Hi Ralph,
>
> On Wed, 25 May 2022 at 05:44, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> I’ve created https://issues.apache.org/jira/browse/LOG4J2-3516 for this.
>>
>> Ralph
>>
>
> Thanks for the fix.
>
> In the meantime I solved the small obstacle to the H2 upgrade (
> https://github.com/eclipse-ee4j/eclipselink/issues/1393), so all
> `log4j-core` dependencies should be up-to-date and CVE-free.
>
> Can we consider https://github.com/apache/logging-log4j2/pull/851 for
> inclusion in 2.18.0: the user who asked for it was quite insistent. :-)
If you are confident in it then feel free to commit it. Remember, we still fundamentally
operate using CTR so even if you are using PRs you don’t necessarily have to wait
for approvals. That said, I glanced at the PR and nothing jumped out at me, but I
didn’t do an exhaustive review.
Ralph
Re: Log4j 2.18.0
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Ralph,
On Wed, 25 May 2022 at 05:44, Ralph Goers <ra...@dslextreme.com>
wrote:
> I’ve created https://issues.apache.org/jira/browse/LOG4J2-3516 for this.
>
> Ralph
>
Thanks for the fix.
In the meantime I solved the small obstacle to the H2 upgrade (
https://github.com/eclipse-ee4j/eclipselink/issues/1393), so all
`log4j-core` dependencies should be up-to-date and CVE-free.
Can we consider https://github.com/apache/logging-log4j2/pull/851 for
inclusion in 2.18.0: the user who asked for it was quite insistent. :-)
Piotr
Re: Log4j 2.18.0
Posted by Ralph Goers <ra...@dslextreme.com>.
I’ve created https://issues.apache.org/jira/browse/LOG4J2-3516 for this.
Ralph
> On May 24, 2022, at 9:41 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
>
>
>> On May 24, 2022, at 2:25 PM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>>
>> The 'log4j:log4j' dependency is only used in some performance tests, which
>> probably should move to `log4j-perf`:
>> https://github.com/apache/logging-log4j2/pull/890.
>> If we also upgrade `h2` the `log4j-api` and `log4j-core` artifacts will not
>> have any vulnerable dependency, whether it is a runtime or test dependency.
>> That is more marketing than anything else, but web sites like MvnRepository
>> do not distinguish yet between the different kinds of vulnerable
>> dependencies.
>
>
> We created log4j-core-its to move the perf tests that were run as sanity checks
> during the build. The stuff in org.apache.logging.log4j.core.async.perf should all
> move there as well.
>
> Ralph
Re: Log4j 2.18.0
Posted by Ralph Goers <ra...@dslextreme.com>.
> On May 24, 2022, at 2:25 PM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>
> The 'log4j:log4j' dependency is only used in some performance tests, which
> probably should move to `log4j-perf`:
> https://github.com/apache/logging-log4j2/pull/890.
> If we also upgrade `h2` the `log4j-api` and `log4j-core` artifacts will not
> have any vulnerable dependency, whether it is a runtime or test dependency.
> That is more marketing than anything else, but web sites like MvnRepository
> do not distinguish yet between the different kinds of vulnerable
> dependencies.
We created log4j-core-its to move the perf tests that were run as sanity checks
during the build. The stuff in org.apache.logging.log4j.core.async.perf should all
move there as well.
Ralph
Re: Log4j 2.18.0
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Volkan,
On Tue, 24 May 2022 at 20:41, Volkan Yazıcı <vo...@yazi.ci> wrote:
> That is a spot on remark with security updates, in particular
> Jackson-related ones, Piotr. Yes, we shouldn't indeed ship 2.18.0 without
> the Jackson updates. I presume you are already taking care of this?
>
Yes, Jackson is updated to a non-vulnerable version and I upgraded a couple
of Maven plugins that didn't fail on tests.
> Removing the `log4j` 1.x dependency from `log4j-core`
>
> What do you exactly mean? `log4j-core` didn't have any `log4j-1.2-api`
> dependencies last time I checked. I can only spot a `log4j:log4j`
> dependency in `test` scope. I am fine with eliminating that too, as long as
> the served functionality either can be replaced by other means or doesn't
> make sense anymore.
>
The 'log4j:log4j' dependency is only used in some performance tests, which
probably should move to `log4j-perf`:
https://github.com/apache/logging-log4j2/pull/890.
If we also upgrade `h2` the `log4j-api` and `log4j-core` artifacts will not
have any vulnerable dependency, whether it is a runtime or test dependency.
That is more marketing than anything else, but web sites like MvnRepository
do not distinguish yet between the different kinds of vulnerable
dependencies.
Piotr
Re: Log4j 2.18.0
Posted by Volkan Yazıcı <vo...@yazi.ci>.
That is a spot on remark with security updates, in particular
Jackson-related ones, Piotr. Yes, we shouldn't indeed ship 2.18.0 without
the Jackson updates. I presume you are already taking care of this?
> Removing the `log4j` 1.x dependency from `log4j-core`
What do you exactly mean? `log4j-core` didn't have any `log4j-1.2-api`
dependencies last time I checked. I can only spot a `log4j:log4j`
dependency in `test` scope. I am fine with eliminating that too, as long as
the served functionality either can be replaced by other means or doesn't
make sense anymore.
On Mon, May 23, 2022 at 11:04 PM Piotr P. Karwasz <pi...@gmail.com>
wrote:
> Hi Ralph,
>
> On Fri, 20 May 2022 at 18:06, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
> > I am working through the last few issues I want to resolve for 2.18.0.
> > I’d like to hope I can have them done today but I might not. I will be
> > traveling tomorrow through Wed, May 25 to visit friends and family. While
> > it is possible I might be able to do the release then, it is unlikely. So
> > right now my plan is to start the process next Wednesday evening MST.
> >
>
> I am a little behind my schedule, so I sent a PR for 2.18.0 only tonight.
> It's a feature addition, so I'd like to profit from a minor version bump.
>
> It would be nice to update some dependencies too before 2.18.0: the
> `log4j-core` page on MvnRepository shows 9 security issues from
> dependencies (
>
> https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core/2.17.2
> ).
> Except `jackson-databind` that we need to upgrade again, the others are in
> the test dependencies. However many people don't look, which dependencies
> are vulnerable and just assume the library is.
>
> Removing the `log4j` 1.x dependency from `log4j-core` (IIRC it's used by a
> performance test) and bumping `h2` would clear most of the vulnerabilities
> from test dependencies.
>
> Piotr
>
Re: Log4j 2.18.0
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Ralph,
On Fri, 20 May 2022 at 18:06, Ralph Goers <ra...@dslextreme.com>
wrote:
> I am working through the last few issues I want to resolve for 2.18.0.
> I’d like to hope I can have them done today but I might not. I will be
> traveling tomorrow through Wed, May 25 to visit friends and family. While
> it is possible I might be able to do the release then, it is unlikely. So
> right now my plan is to start the process next Wednesday evening MST.
>
I am a little behind my schedule, so I sent a PR for 2.18.0 only tonight.
It's a feature addition, so I'd like to profit from a minor version bump.
It would be nice to update some dependencies too before 2.18.0: the
`log4j-core` page on MvnRepository shows 9 security issues from
dependencies (
https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core/2.17.2).
Except `jackson-databind` that we need to upgrade again, the others are in
the test dependencies. However many people don't look, which dependencies
are vulnerable and just assume the library is.
Removing the `log4j` 1.x dependency from `log4j-core` (IIRC it's used by a
performance test) and bumping `h2` would clear most of the vulnerabilities
from test dependencies.
Piotr