You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Leo Simons <ma...@leosimons.com> on 2021/12/17 17:24:32 UTC
Log4J 1.x progress, pull request(s), plans
Hey,
Progress today
----
As mentioned I made a draft PR for the branch I'm working on:
https://github.com/apache/log4j/pull/16
My main progress today was to get the unit test suite working reliably
(dozens of tests were disabled because they had flaky results), and then to
get build and test to run reliably on a bunch of different JDK/toolchain/OS
combos, using github actions for CI:
https://github.com/lsimons/log4j/actions/runs/1593087224
I also read through the SyslogAppender which I thought about
disabling completely, but have opted for a stern warning instead for any
configs that write to non-localhost.
In the net package, SMTPAppender still needs more of an opinion on what to
do exactly (see some notes on the e-mail thread Tony started).
Other PRs
----
I've also cherry-picked a couple of reasonable PRs into the branch I'm
working on:
https://github.com/apache/log4j/pull/13 (by Geertjan Wielenga)
https://github.com/apache/log4j/pull/10 (by Vincent Privat)
For the remaining ones I went through them and wrote suggestions for what I
think should happen, which amounts to: all PRs except for the new #16
should be closed. (I don't have permission to click "Close" of course.)
Integration tests
----
Existing test suite took so much time that I didn't get around to starting
on any integration tests yet.
I would like to have some fixture projects set up into which to auto-inject
different problematic config files and 1.x libraries, assert there is a
problem, replace with the new library, assert it's ok.
Wondering if it's easy to make it all a bit sysadmin friendly (i.e. shell
scripts / docker / ...), so you don't need to know java to see the problem
or to verify the solution.
...and then it'd make sense to me to have another git repo.
Cheers,
Leo
Re: Log4J 1.x progress, pull request(s), plans
Posted by Matt Sicker <bo...@gmail.com>.
It's possible that it's not buildable without updates to the build
scripts. If that's the case, then they should be updated.
On Fri, Dec 17, 2021 at 12:28 PM Ralph Goers <ra...@dslextreme.com> wrote:
>
> I am still questioning the plan. If you are planning on just creating a security release
> and then having the project go back to its coffin then I am not sure why all the tooling
> is needed. OTOH, if you want to resurrect the project then this really should go through
> the ASF incubator with the Logging Services project as the sponsor.
>
> Ralph
>
> > On Dec 17, 2021, at 10:24 AM, Leo Simons <ma...@leosimons.com> wrote:
> >
> > Hey,
> >
> > Progress today
> > ----
> > As mentioned I made a draft PR for the branch I'm working on:
> >
> > https://github.com/apache/log4j/pull/16
> >
> > My main progress today was to get the unit test suite working reliably
> > (dozens of tests were disabled because they had flaky results), and then to
> > get build and test to run reliably on a bunch of different JDK/toolchain/OS
> > combos, using github actions for CI:
> >
> > https://github.com/lsimons/log4j/actions/runs/1593087224
> >
> > I also read through the SyslogAppender which I thought about
> > disabling completely, but have opted for a stern warning instead for any
> > configs that write to non-localhost.
> >
> > In the net package, SMTPAppender still needs more of an opinion on what to
> > do exactly (see some notes on the e-mail thread Tony started).
> >
> > Other PRs
> > ----
> > I've also cherry-picked a couple of reasonable PRs into the branch I'm
> > working on:
> >
> > https://github.com/apache/log4j/pull/13 (by Geertjan Wielenga)
> > https://github.com/apache/log4j/pull/10 (by Vincent Privat)
> >
> > For the remaining ones I went through them and wrote suggestions for what I
> > think should happen, which amounts to: all PRs except for the new #16
> > should be closed. (I don't have permission to click "Close" of course.)
> >
> > Integration tests
> > ----
> > Existing test suite took so much time that I didn't get around to starting
> > on any integration tests yet.
> >
> > I would like to have some fixture projects set up into which to auto-inject
> > different problematic config files and 1.x libraries, assert there is a
> > problem, replace with the new library, assert it's ok.
> >
> > Wondering if it's easy to make it all a bit sysadmin friendly (i.e. shell
> > scripts / docker / ...), so you don't need to know java to see the problem
> > or to verify the solution.
> >
> > ...and then it'd make sense to me to have another git repo.
> >
> >
> > Cheers,
> >
> >
> > Leo
>
Re: Log4J 1.x progress, pull request(s), plans
Posted by Gary Gregory <ga...@gmail.com>.
On Sun, Dec 19, 2021 at 3:33 PM Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> Ralph>if you want to resurrect the project then this really should go
> through
> Ralph>the ASF incubator with the Logging Services project as the sponsor
>
> Ralph,
> Do you think you know similar cases?
> Could you please suggest the procedure for resurrection?
>
> I guess it would look strange if I submit a mail to the incubator saying I
> want to take over log4j 1.x.
Vladimir,
You can't "take over" a Log4j component any more than I can or anyone
else. We have the Apache Logging Services top-level project [1] and
Log4j 1 and 2 are two of its components, as are Log4cxx, Log4Net, and
so on.
Gary
[1] https://logging.apache.org/
>
> Vladimir
Re: Log4J 1.x progress, pull request(s), plans
Posted by Vladimir Sitnikov <si...@gmail.com>.
>The alternative is to polish the 1.x compatibility in 2.x
Making sure the compatibility is 100% would be way harder than reincubating
1.x
"maintaining" and "releasing" 1.x is not hard (e.g. I can do it), so I do
not buy "1.x is not maintained".
Vladimir
Re: Log4J 1.x progress, pull request(s), plans
Posted by Apache <ra...@dslextreme.com>.
Fwiw, this sounds like a god plan to me.
Ralph
> On Dec 23, 2021, at 6:51 AM, Leo Simons <ma...@leosimons.com> wrote:
>
> Thanks for chipping in Christian! Your detailed notes from back then helped
> a ton figure basic things out.
>
> What I did for the PRs I made is to
>
> * also check in the 32 bit 1.2.17 dll from the binary release, like was
> already done for 64 bit,
> * have the maven build not auto-attempt to build it,
> * make its single unit test not even attempt to run except on windows,
> * add a matrix build that includes running on windows so that the
> windows-only test gets run frequently
> * did a little test on a windows machine with one of the DLLs
>
> Basically does for the 32 bit DLL what was already done for the 64 bit DLL.
>
> I think it’s good enough like that.
>
> Additional todo could be
> * add better INSTALL instructions for how to rebuild the dlls with ant
> * add another CI / GitHub action build that rebuilds the DLLs
>
> I think it is best to produce the DLLs on windows and the official release
> on linux, and to not attempt to have build orchestration to glue those
> together. It’s an exceptionally messy thing to rebuild from source without
> manual step, while the manual step is easy.
>
> Cheers,
>
> Leo
>
>
>> On Thu, 23 Dec 2021 at 14:34, Gary Gregory <ga...@gmail.com> wrote:
>>
>> On Thu, Dec 23, 2021 at 8:20 AM Christian Grobmeier <gr...@apache.org>
>> wrote:
>>
>>>
>>> On Thu, Dec 23, 2021, at 14:05, Gary Gregory wrote:
>>>> One of the difficulties was likely related to building the Windows DLLs
>>>> for
>>>> using the Windows Event Log Appender (
>>>>
>>>
>> https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/nt/NTEventLogAppender.html
>>> ).
>>>> I remember that being challenging. I can't recall if we signed the DLLs
>>>> like we might do for Apache Commons Daemons Windows binaries. Another
>>>> hurdle.
>>>
>>> Correct, the DLL is even in the codebase.
>>>
>>>
>> https://github.com/apache/logging-log4j1/blob/trunk/NTEventLogAppender.amd64.dll
>>>
>>> If we would remove that Appender, it would be much easier to build, when
>> I
>>> remember correctly.
>>> Would - in this case - an 1.2.18 with a NoOp NTEventLogAppender be OK?
>>>
>>
>> Sadly, no. We cannot break binary compatibility, that would create a bigger
>> mess: Jar hell. Some folks would argue for breaking BC but that's a no-go
>> me.
>>
>> I feel like the projects I've worked on like Apache Commons and
>> HttpComponents have benefitted *massively* from providing binary
>> compatibility. Giving users drop-in replacements is a huge help.
>>
>> Recall that Apache officially *only releases source code*, and that source
>> code must be buildable, no matter how complex the instructions. Any
>> binaries are only provided as a convenience, that includes jar files and
>> DLLs.
>>
>> Gary
>>
>>
>>>>
>>>> FWIW, my opinion has been to NOT resurrect 1.x and put our energies
>> into
>>>> improving the 1.2 bridge and configuration file support we already have
>>> in
>>>> 2.x. That said, if we decides to move forward with 1.2.18, I'll help.
>>>>
>>>> No matter what, it needs to be a decision made carefully and not in
>>> haste.
>>>>
>>>
>>> +1
>>>
>>>> Gary
>>>>
>>>> On Thu, Dec 23, 2021 at 7:56 AM Christian Grobmeier <
>>> grobmeier@apache.org>
>>>> wrote:
>>>>
>>>>> Hello
>>>>>
>>>>> I have been the person cutting the 1.2.17 release and what I remember
>>> was
>>>>> it was a super hard build. I had to install some VMs because there
>> were
>>>>> weird dependencies to this build. Building it fully will not be easy,
>>> but I
>>>>> can also look into some mails whatever I found from that time.
>>>>> Here is some build info.:
>>>>> https://github.com/apache/logging-log4j1/blob/trunk/INSTALL
>>>>> Some unit tests only run with a Windows VM
>>>>>
>>>>> It would be easier to remove some components, but BC is broken then.
>>>>>
>>>>> We told people in August 2015 this is EOL. I am honestly surprised
>> that
>>> we
>>>>> discuss a new release after 7 years. To my understanding the
>> JMSAppender
>>>>> issue is not as critical (just don't configure it). If a
>>> reconfiguration of
>>>>> system is not on the cards, I wonder if upgrading from 1.2.17 to
>> 1.2.18
>>> is.
>>>>>
>>>>> That said i don't think we should resurrect it.
>>>>>
>>>>> If somebody really wants to work on, I also don't think we should go
>>>>> through the incubator. We can do this using the normal processes and
>>> apply
>>>>> patches, vote on new committers etc.
>>>>>
>>>>> My 2 cents.
>>>>>
>>>>> Christian
>>>>>
>>>>>
>>>>> On Mon, Dec 20, 2021, at 01:36, Gary Gregory wrote:
>>>>>> Improving legacy compatibility is what I've been pushing. I agree
>> with
>>>>>> Matt. IMO resurrecting 1.x sets a bad precedent and is a proverbial
>>> can
>>>>> of
>>>>>> worms.
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> On Sun, Dec 19, 2021, 17:55 Matt Sicker <bo...@gmail.com> wrote:
>>>>>>
>>>>>>> The alternative is to polish the 1.x compatibility in 2.x which is
>>> both
>>>>>>> actively maintained and much easier to get releases published. Then
>>>>> users
>>>>>>> on 1.x can more easily upgrade to 2.x. I can almost guarantee that
>>>>>>> regardless of how many warnings we add to a potential 1.x release,
>>> we’ll
>>>>>>> get inundated with CVE reports, bug reports, and email, all related
>>>>> solely
>>>>>>> to 1.x which none of us wish to maintain (especially given most of
>> us
>>>>>>> weren’t even involved in 1.x back when it was in development).
>>>>>>> --
>>>>>>> Matt Sicker
>>>>>>>
>>>>>>>> On Dec 19, 2021, at 16:48, Vladimir Sitnikov <
>>>>>>> sitnikov.vladimir@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Matt>but at least one release using the normal ASF release
>>>>> requirements
>>>>>>> is
>>>>>>>> required to graduate.
>>>>>>>>
>>>>>>>> Thanks for the reminder, and I am sure preparing the release
>> won't
>>> be
>>>>> an
>>>>>>>> issue. I refactored release scripts for both Calcite and JMeter,
>>> and
>>>>> I am
>>>>>>>> sure log4j 1.x is doable.
>>>>>>>>
>>>>>>>>> compared to the alternatives discussed in this thread.
>>>>>>>>
>>>>>>>> I must be missing the alternarives.
>>>>>>>> Can you please highlight them?
>>>>>>>>
>>>>>>>> There were multiple suggestions and various PRs from external
>>>>>>> contributora,
>>>>>>>> yet the committers respond with vaugue messages.
>>>>>>>>
>>>>>>>> The code must be buildable, so moving to Git, and adding GitHub
>> CI
>>> is
>>>>> the
>>>>>>>> mandatory step.
>>>>>>>> Of course, the existing PMC members and committers might have
>>>>> opinions on
>>>>>>>> the way to fix the issues, however I see no reasons for the team
>> to
>>>>> deny
>>>>>>>> Git.
>>>>>>>>
>>>>>>>> The migration to Git consumes absolutely no resources from
>>> committers,
>>>>>>>> except a couple of +1 votes.
>>>>>>>>
>>>>>>>> Unfortunately, even a trivial improvement like Git is ignored by
>>>>> Logging
>>>>>>>> PMC.
>>>>>>>>
>>>>>>>> So I take Ralph's suggestion to reestablish the new PMC for log4j
>>> 1.x
>>>>>>>> seriously.
>>>>>>>>
>>>>>>>> Vladimir
>>>>>>>
>>>>>>>
>>>>>
>>>
>>
Re: Log4J 1.x progress, pull request(s), plans
Posted by Ralph Goers <ra...@dslextreme.com>.
Leo,
I have created the main branch from the v1_2_17 tag. It looks like I will have to create a
Jira for Infra to switch the default as it looks like we don’t have access to the GitHub
tooling to do that.
Ralph
> On Dec 23, 2021, at 8:39 AM, Leo Simons <ma...@leosimons.com> wrote:
>
> On Thu, 23 Dec 2021 at 15:43, Christian Grobmeier <gr...@apache.org>
> wrote:
>
>> I didn't see the PRs though - are they still local on your box?
>
>
> On the wrong repo and lacking a target branch:
>
> https://github.com/apache/log4j/pull/17
> https://github.com/apache/log4j/pull/16
>
> From
> https://github.com/lsimons/log4j
>
> For #17 I have it split across a couple branches in my forked repo, that
> could be their own PRs, but was waiting for feedback and a writeable repo.
>
> I am not near a laptop now so won’t contribute code until mid next week.
> Hope someone can pick up where I left off.
>
> Cheers!
>
> Leo
Re: Log4J 1.x progress, pull request(s), plans
Posted by Gary Gregory <ga...@gmail.com>.
The main point is, I thought, we agreed to not say/do anything until we
have a PLAN. See also Ralph's request to call for a VOTE or wrap up the
email with the list of options.
Gary
On Tue, Dec 28, 2021 at 2:08 PM Matt Sicker <bo...@gmail.com> wrote:
> I looked through most of the PR (besides the pom changes). Seems good so
> far, but I’d like someone else to also verify.
> --
> Matt Sicker
>
> > On Dec 28, 2021, at 12:36, Vladimir Sitnikov <
> sitnikov.vladimir@gmail.com> wrote:
> >
> > Leo, All,
> >
> > I've reviewed Leo's changes and filed a PR
> > https://github.com/apache/logging-log4j1/pull/18
> > CI: https://github.com/vlsi/log4j/runs/4652588702
> >
> > I think it is worth separating "build script refactoring" from "bugfix"
> > changes.
> >
> > Does anybody have cycles to review and merge "build script refactoring"?
> >
> > Notable changes on top of Leo's commits:
> > a) I simplified toolchains: the build requires Java <= 1.8 or it requires
> > Java 1.8 (exactly) toolchain to be present.
> > b) I skipped "test: delete several broken low-quality tests".
> > In practice, what Leo calls "broken tests" are tests that need to be
> > executed in
> > their own JVM (e.g. with special values for log4j.configuration, etc).
> > I kept the tests in ignored mode.
> >
> > Vladimir
>
>
Re: Log4J 1.x progress, pull request(s), plans
Posted by Matt Sicker <bo...@gmail.com>.
I looked through most of the PR (besides the pom changes). Seems good so far, but I’d like someone else to also verify.
--
Matt Sicker
> On Dec 28, 2021, at 12:36, Vladimir Sitnikov <si...@gmail.com> wrote:
>
> Leo, All,
>
> I've reviewed Leo's changes and filed a PR
> https://github.com/apache/logging-log4j1/pull/18
> CI: https://github.com/vlsi/log4j/runs/4652588702
>
> I think it is worth separating "build script refactoring" from "bugfix"
> changes.
>
> Does anybody have cycles to review and merge "build script refactoring"?
>
> Notable changes on top of Leo's commits:
> a) I simplified toolchains: the build requires Java <= 1.8 or it requires
> Java 1.8 (exactly) toolchain to be present.
> b) I skipped "test: delete several broken low-quality tests".
> In practice, what Leo calls "broken tests" are tests that need to be
> executed in
> their own JVM (e.g. with special values for log4j.configuration, etc).
> I kept the tests in ignored mode.
>
> Vladimir
Re: Log4J 1.x progress, pull request(s), plans
Posted by Vladimir Sitnikov <si...@gmail.com>.
Leo, All,
I've reviewed Leo's changes and filed a PR
https://github.com/apache/logging-log4j1/pull/18
CI: https://github.com/vlsi/log4j/runs/4652588702
I think it is worth separating "build script refactoring" from "bugfix"
changes.
Does anybody have cycles to review and merge "build script refactoring"?
Notable changes on top of Leo's commits:
a) I simplified toolchains: the build requires Java <= 1.8 or it requires
Java 1.8 (exactly) toolchain to be present.
b) I skipped "test: delete several broken low-quality tests".
In practice, what Leo calls "broken tests" are tests that need to be
executed in
their own JVM (e.g. with special values for log4j.configuration, etc).
I kept the tests in ignored mode.
Vladimir
Re: Log4J 1.x progress, pull request(s), plans
Posted by Christian Grobmeier <gr...@apache.org>.
On Thu, Dec 23, 2021, at 16:39, Leo Simons wrote:
> On Thu, 23 Dec 2021 at 15:43, Christian Grobmeier <gr...@apache.org>
> wrote:
>
>> I didn't see the PRs though - are they still local on your box?
>
>
> On the wrong repo and lacking a target branch:
>
> https://github.com/apache/log4j/pull/17
> https://github.com/apache/log4j/pull/16
>
> From
> https://github.com/lsimons/log4j
Thanks for the pointer!
> For #17 I have it split across a couple branches in my forked repo, that
> could be their own PRs, but was waiting for feedback and a writeable repo.
>
> I am not near a laptop now so won’t contribute code until mid next week.
> Hope someone can pick up where I left off.
Don't worry, actually I am taking a few off days too. :-)
Kind regards,
Christian
>
> Cheers!
>
> Leo
Re: Log4J 1.x progress, pull request(s), plans
Posted by Leo Simons <ma...@leosimons.com>.
On Thu, 23 Dec 2021 at 15:43, Christian Grobmeier <gr...@apache.org>
wrote:
> I didn't see the PRs though - are they still local on your box?
On the wrong repo and lacking a target branch:
https://github.com/apache/log4j/pull/17
https://github.com/apache/log4j/pull/16
From
https://github.com/lsimons/log4j
For #17 I have it split across a couple branches in my forked repo, that
could be their own PRs, but was waiting for feedback and a writeable repo.
I am not near a laptop now so won’t contribute code until mid next week.
Hope someone can pick up where I left off.
Cheers!
Leo
Re: Log4J 1.x progress, pull request(s), plans
Posted by Christian Grobmeier <gr...@apache.org>.
Hi
On Thu, Dec 23, 2021, at 14:51, Leo Simons wrote:
> Thanks for chipping in Christian! Your detailed notes from back then helped
> a ton figure basic things out.
>
> What I did for the PRs I made is to
>
> * also check in the 32 bit 1.2.17 dll from the binary release, like was
> already done for 64 bit,
> * have the maven build not auto-attempt to build it,
> * make its single unit test not even attempt to run except on windows,
> * add a matrix build that includes running on windows so that the
> windows-only test gets run frequently
> * did a little test on a windows machine with one of the DLLs
>
> Basically does for the 32 bit DLL what was already done for the 64 bit DLL.
>
> I think it’s good enough like that.
>
> Additional todo could be
> * add better INSTALL instructions for how to rebuild the dlls with ant
Definitely. It looked like a waste of time back then with 2.0 approaching.
Personally I have no access to a Windows machine. I cannot run the windows build part.
Apart from that, I am helping with the release of a 1.2.18, even if it hurts like hell
> * add another CI / GitHub action build that rebuilds the DLLs
>
> I think it is best to produce the DLLs on windows and the official release
> on linux, and to not attempt to have build orchestration to glue those
> together. It’s an exceptionally messy thing to rebuild from source without
> manual step, while the manual step is easy.
I think so.
I didn't see the PRs though - are they still local on your box?
Kind regards,
Christian
>
> Cheers,
>
> Leo
>
>
> On Thu, 23 Dec 2021 at 14:34, Gary Gregory <ga...@gmail.com> wrote:
>
>> On Thu, Dec 23, 2021 at 8:20 AM Christian Grobmeier <gr...@apache.org>
>> wrote:
>>
>> >
>> > On Thu, Dec 23, 2021, at 14:05, Gary Gregory wrote:
>> > > One of the difficulties was likely related to building the Windows DLLs
>> > > for
>> > > using the Windows Event Log Appender (
>> > >
>> >
>> https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/nt/NTEventLogAppender.html
>> > ).
>> > > I remember that being challenging. I can't recall if we signed the DLLs
>> > > like we might do for Apache Commons Daemons Windows binaries. Another
>> > > hurdle.
>> >
>> > Correct, the DLL is even in the codebase.
>> >
>> >
>> https://github.com/apache/logging-log4j1/blob/trunk/NTEventLogAppender.amd64.dll
>> >
>> > If we would remove that Appender, it would be much easier to build, when
>> I
>> > remember correctly.
>> > Would - in this case - an 1.2.18 with a NoOp NTEventLogAppender be OK?
>> >
>>
>> Sadly, no. We cannot break binary compatibility, that would create a bigger
>> mess: Jar hell. Some folks would argue for breaking BC but that's a no-go
>> me.
>>
>> I feel like the projects I've worked on like Apache Commons and
>> HttpComponents have benefitted *massively* from providing binary
>> compatibility. Giving users drop-in replacements is a huge help.
>>
>> Recall that Apache officially *only releases source code*, and that source
>> code must be buildable, no matter how complex the instructions. Any
>> binaries are only provided as a convenience, that includes jar files and
>> DLLs.
>>
>> Gary
>>
>>
>> > >
>> > > FWIW, my opinion has been to NOT resurrect 1.x and put our energies
>> into
>> > > improving the 1.2 bridge and configuration file support we already have
>> > in
>> > > 2.x. That said, if we decides to move forward with 1.2.18, I'll help.
>> > >
>> > > No matter what, it needs to be a decision made carefully and not in
>> > haste.
>> > >
>> >
>> > +1
>> >
>> > > Gary
>> > >
>> > > On Thu, Dec 23, 2021 at 7:56 AM Christian Grobmeier <
>> > grobmeier@apache.org>
>> > > wrote:
>> > >
>> > >> Hello
>> > >>
>> > >> I have been the person cutting the 1.2.17 release and what I remember
>> > was
>> > >> it was a super hard build. I had to install some VMs because there
>> were
>> > >> weird dependencies to this build. Building it fully will not be easy,
>> > but I
>> > >> can also look into some mails whatever I found from that time.
>> > >> Here is some build info.:
>> > >> https://github.com/apache/logging-log4j1/blob/trunk/INSTALL
>> > >> Some unit tests only run with a Windows VM
>> > >>
>> > >> It would be easier to remove some components, but BC is broken then.
>> > >>
>> > >> We told people in August 2015 this is EOL. I am honestly surprised
>> that
>> > we
>> > >> discuss a new release after 7 years. To my understanding the
>> JMSAppender
>> > >> issue is not as critical (just don't configure it). If a
>> > reconfiguration of
>> > >> system is not on the cards, I wonder if upgrading from 1.2.17 to
>> 1.2.18
>> > is.
>> > >>
>> > >> That said i don't think we should resurrect it.
>> > >>
>> > >> If somebody really wants to work on, I also don't think we should go
>> > >> through the incubator. We can do this using the normal processes and
>> > apply
>> > >> patches, vote on new committers etc.
>> > >>
>> > >> My 2 cents.
>> > >>
>> > >> Christian
>> > >>
>> > >>
>> > >> On Mon, Dec 20, 2021, at 01:36, Gary Gregory wrote:
>> > >> > Improving legacy compatibility is what I've been pushing. I agree
>> with
>> > >> > Matt. IMO resurrecting 1.x sets a bad precedent and is a proverbial
>> > can
>> > >> of
>> > >> > worms.
>> > >> >
>> > >> > Gary
>> > >> >
>> > >> > On Sun, Dec 19, 2021, 17:55 Matt Sicker <bo...@gmail.com> wrote:
>> > >> >
>> > >> >> The alternative is to polish the 1.x compatibility in 2.x which is
>> > both
>> > >> >> actively maintained and much easier to get releases published. Then
>> > >> users
>> > >> >> on 1.x can more easily upgrade to 2.x. I can almost guarantee that
>> > >> >> regardless of how many warnings we add to a potential 1.x release,
>> > we’ll
>> > >> >> get inundated with CVE reports, bug reports, and email, all related
>> > >> solely
>> > >> >> to 1.x which none of us wish to maintain (especially given most of
>> us
>> > >> >> weren’t even involved in 1.x back when it was in development).
>> > >> >> --
>> > >> >> Matt Sicker
>> > >> >>
>> > >> >> > On Dec 19, 2021, at 16:48, Vladimir Sitnikov <
>> > >> >> sitnikov.vladimir@gmail.com> wrote:
>> > >> >> >
>> > >> >> > Matt>but at least one release using the normal ASF release
>> > >> requirements
>> > >> >> is
>> > >> >> > required to graduate.
>> > >> >> >
>> > >> >> > Thanks for the reminder, and I am sure preparing the release
>> won't
>> > be
>> > >> an
>> > >> >> > issue. I refactored release scripts for both Calcite and JMeter,
>> > and
>> > >> I am
>> > >> >> > sure log4j 1.x is doable.
>> > >> >> >
>> > >> >> >> compared to the alternatives discussed in this thread.
>> > >> >> >
>> > >> >> > I must be missing the alternarives.
>> > >> >> > Can you please highlight them?
>> > >> >> >
>> > >> >> > There were multiple suggestions and various PRs from external
>> > >> >> contributora,
>> > >> >> > yet the committers respond with vaugue messages.
>> > >> >> >
>> > >> >> > The code must be buildable, so moving to Git, and adding GitHub
>> CI
>> > is
>> > >> the
>> > >> >> > mandatory step.
>> > >> >> > Of course, the existing PMC members and committers might have
>> > >> opinions on
>> > >> >> > the way to fix the issues, however I see no reasons for the team
>> to
>> > >> deny
>> > >> >> > Git.
>> > >> >> >
>> > >> >> > The migration to Git consumes absolutely no resources from
>> > committers,
>> > >> >> > except a couple of +1 votes.
>> > >> >> >
>> > >> >> > Unfortunately, even a trivial improvement like Git is ignored by
>> > >> Logging
>> > >> >> > PMC.
>> > >> >> >
>> > >> >> > So I take Ralph's suggestion to reestablish the new PMC for log4j
>> > 1.x
>> > >> >> > seriously.
>> > >> >> >
>> > >> >> > Vladimir
>> > >> >>
>> > >> >>
>> > >>
>> >
>>
Re: Log4J 1.x progress, pull request(s), plans
Posted by Leo Simons <ma...@leosimons.com>.
Thanks for chipping in Christian! Your detailed notes from back then helped
a ton figure basic things out.
What I did for the PRs I made is to
* also check in the 32 bit 1.2.17 dll from the binary release, like was
already done for 64 bit,
* have the maven build not auto-attempt to build it,
* make its single unit test not even attempt to run except on windows,
* add a matrix build that includes running on windows so that the
windows-only test gets run frequently
* did a little test on a windows machine with one of the DLLs
Basically does for the 32 bit DLL what was already done for the 64 bit DLL.
I think it’s good enough like that.
Additional todo could be
* add better INSTALL instructions for how to rebuild the dlls with ant
* add another CI / GitHub action build that rebuilds the DLLs
I think it is best to produce the DLLs on windows and the official release
on linux, and to not attempt to have build orchestration to glue those
together. It’s an exceptionally messy thing to rebuild from source without
manual step, while the manual step is easy.
Cheers,
Leo
On Thu, 23 Dec 2021 at 14:34, Gary Gregory <ga...@gmail.com> wrote:
> On Thu, Dec 23, 2021 at 8:20 AM Christian Grobmeier <gr...@apache.org>
> wrote:
>
> >
> > On Thu, Dec 23, 2021, at 14:05, Gary Gregory wrote:
> > > One of the difficulties was likely related to building the Windows DLLs
> > > for
> > > using the Windows Event Log Appender (
> > >
> >
> https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/nt/NTEventLogAppender.html
> > ).
> > > I remember that being challenging. I can't recall if we signed the DLLs
> > > like we might do for Apache Commons Daemons Windows binaries. Another
> > > hurdle.
> >
> > Correct, the DLL is even in the codebase.
> >
> >
> https://github.com/apache/logging-log4j1/blob/trunk/NTEventLogAppender.amd64.dll
> >
> > If we would remove that Appender, it would be much easier to build, when
> I
> > remember correctly.
> > Would - in this case - an 1.2.18 with a NoOp NTEventLogAppender be OK?
> >
>
> Sadly, no. We cannot break binary compatibility, that would create a bigger
> mess: Jar hell. Some folks would argue for breaking BC but that's a no-go
> me.
>
> I feel like the projects I've worked on like Apache Commons and
> HttpComponents have benefitted *massively* from providing binary
> compatibility. Giving users drop-in replacements is a huge help.
>
> Recall that Apache officially *only releases source code*, and that source
> code must be buildable, no matter how complex the instructions. Any
> binaries are only provided as a convenience, that includes jar files and
> DLLs.
>
> Gary
>
>
> > >
> > > FWIW, my opinion has been to NOT resurrect 1.x and put our energies
> into
> > > improving the 1.2 bridge and configuration file support we already have
> > in
> > > 2.x. That said, if we decides to move forward with 1.2.18, I'll help.
> > >
> > > No matter what, it needs to be a decision made carefully and not in
> > haste.
> > >
> >
> > +1
> >
> > > Gary
> > >
> > > On Thu, Dec 23, 2021 at 7:56 AM Christian Grobmeier <
> > grobmeier@apache.org>
> > > wrote:
> > >
> > >> Hello
> > >>
> > >> I have been the person cutting the 1.2.17 release and what I remember
> > was
> > >> it was a super hard build. I had to install some VMs because there
> were
> > >> weird dependencies to this build. Building it fully will not be easy,
> > but I
> > >> can also look into some mails whatever I found from that time.
> > >> Here is some build info.:
> > >> https://github.com/apache/logging-log4j1/blob/trunk/INSTALL
> > >> Some unit tests only run with a Windows VM
> > >>
> > >> It would be easier to remove some components, but BC is broken then.
> > >>
> > >> We told people in August 2015 this is EOL. I am honestly surprised
> that
> > we
> > >> discuss a new release after 7 years. To my understanding the
> JMSAppender
> > >> issue is not as critical (just don't configure it). If a
> > reconfiguration of
> > >> system is not on the cards, I wonder if upgrading from 1.2.17 to
> 1.2.18
> > is.
> > >>
> > >> That said i don't think we should resurrect it.
> > >>
> > >> If somebody really wants to work on, I also don't think we should go
> > >> through the incubator. We can do this using the normal processes and
> > apply
> > >> patches, vote on new committers etc.
> > >>
> > >> My 2 cents.
> > >>
> > >> Christian
> > >>
> > >>
> > >> On Mon, Dec 20, 2021, at 01:36, Gary Gregory wrote:
> > >> > Improving legacy compatibility is what I've been pushing. I agree
> with
> > >> > Matt. IMO resurrecting 1.x sets a bad precedent and is a proverbial
> > can
> > >> of
> > >> > worms.
> > >> >
> > >> > Gary
> > >> >
> > >> > On Sun, Dec 19, 2021, 17:55 Matt Sicker <bo...@gmail.com> wrote:
> > >> >
> > >> >> The alternative is to polish the 1.x compatibility in 2.x which is
> > both
> > >> >> actively maintained and much easier to get releases published. Then
> > >> users
> > >> >> on 1.x can more easily upgrade to 2.x. I can almost guarantee that
> > >> >> regardless of how many warnings we add to a potential 1.x release,
> > we’ll
> > >> >> get inundated with CVE reports, bug reports, and email, all related
> > >> solely
> > >> >> to 1.x which none of us wish to maintain (especially given most of
> us
> > >> >> weren’t even involved in 1.x back when it was in development).
> > >> >> --
> > >> >> Matt Sicker
> > >> >>
> > >> >> > On Dec 19, 2021, at 16:48, Vladimir Sitnikov <
> > >> >> sitnikov.vladimir@gmail.com> wrote:
> > >> >> >
> > >> >> > Matt>but at least one release using the normal ASF release
> > >> requirements
> > >> >> is
> > >> >> > required to graduate.
> > >> >> >
> > >> >> > Thanks for the reminder, and I am sure preparing the release
> won't
> > be
> > >> an
> > >> >> > issue. I refactored release scripts for both Calcite and JMeter,
> > and
> > >> I am
> > >> >> > sure log4j 1.x is doable.
> > >> >> >
> > >> >> >> compared to the alternatives discussed in this thread.
> > >> >> >
> > >> >> > I must be missing the alternarives.
> > >> >> > Can you please highlight them?
> > >> >> >
> > >> >> > There were multiple suggestions and various PRs from external
> > >> >> contributora,
> > >> >> > yet the committers respond with vaugue messages.
> > >> >> >
> > >> >> > The code must be buildable, so moving to Git, and adding GitHub
> CI
> > is
> > >> the
> > >> >> > mandatory step.
> > >> >> > Of course, the existing PMC members and committers might have
> > >> opinions on
> > >> >> > the way to fix the issues, however I see no reasons for the team
> to
> > >> deny
> > >> >> > Git.
> > >> >> >
> > >> >> > The migration to Git consumes absolutely no resources from
> > committers,
> > >> >> > except a couple of +1 votes.
> > >> >> >
> > >> >> > Unfortunately, even a trivial improvement like Git is ignored by
> > >> Logging
> > >> >> > PMC.
> > >> >> >
> > >> >> > So I take Ralph's suggestion to reestablish the new PMC for log4j
> > 1.x
> > >> >> > seriously.
> > >> >> >
> > >> >> > Vladimir
> > >> >>
> > >> >>
> > >>
> >
>
Re: Log4J 1.x progress, pull request(s), plans
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Dec 23, 2021 at 8:20 AM Christian Grobmeier <gr...@apache.org>
wrote:
>
> On Thu, Dec 23, 2021, at 14:05, Gary Gregory wrote:
> > One of the difficulties was likely related to building the Windows DLLs
> > for
> > using the Windows Event Log Appender (
> >
> https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/nt/NTEventLogAppender.html
> ).
> > I remember that being challenging. I can't recall if we signed the DLLs
> > like we might do for Apache Commons Daemons Windows binaries. Another
> > hurdle.
>
> Correct, the DLL is even in the codebase.
>
> https://github.com/apache/logging-log4j1/blob/trunk/NTEventLogAppender.amd64.dll
>
> If we would remove that Appender, it would be much easier to build, when I
> remember correctly.
> Would - in this case - an 1.2.18 with a NoOp NTEventLogAppender be OK?
>
Sadly, no. We cannot break binary compatibility, that would create a bigger
mess: Jar hell. Some folks would argue for breaking BC but that's a no-go
me.
I feel like the projects I've worked on like Apache Commons and
HttpComponents have benefitted *massively* from providing binary
compatibility. Giving users drop-in replacements is a huge help.
Recall that Apache officially *only releases source code*, and that source
code must be buildable, no matter how complex the instructions. Any
binaries are only provided as a convenience, that includes jar files and
DLLs.
Gary
> >
> > FWIW, my opinion has been to NOT resurrect 1.x and put our energies into
> > improving the 1.2 bridge and configuration file support we already have
> in
> > 2.x. That said, if we decides to move forward with 1.2.18, I'll help.
> >
> > No matter what, it needs to be a decision made carefully and not in
> haste.
> >
>
> +1
>
> > Gary
> >
> > On Thu, Dec 23, 2021 at 7:56 AM Christian Grobmeier <
> grobmeier@apache.org>
> > wrote:
> >
> >> Hello
> >>
> >> I have been the person cutting the 1.2.17 release and what I remember
> was
> >> it was a super hard build. I had to install some VMs because there were
> >> weird dependencies to this build. Building it fully will not be easy,
> but I
> >> can also look into some mails whatever I found from that time.
> >> Here is some build info.:
> >> https://github.com/apache/logging-log4j1/blob/trunk/INSTALL
> >> Some unit tests only run with a Windows VM
> >>
> >> It would be easier to remove some components, but BC is broken then.
> >>
> >> We told people in August 2015 this is EOL. I am honestly surprised that
> we
> >> discuss a new release after 7 years. To my understanding the JMSAppender
> >> issue is not as critical (just don't configure it). If a
> reconfiguration of
> >> system is not on the cards, I wonder if upgrading from 1.2.17 to 1.2.18
> is.
> >>
> >> That said i don't think we should resurrect it.
> >>
> >> If somebody really wants to work on, I also don't think we should go
> >> through the incubator. We can do this using the normal processes and
> apply
> >> patches, vote on new committers etc.
> >>
> >> My 2 cents.
> >>
> >> Christian
> >>
> >>
> >> On Mon, Dec 20, 2021, at 01:36, Gary Gregory wrote:
> >> > Improving legacy compatibility is what I've been pushing. I agree with
> >> > Matt. IMO resurrecting 1.x sets a bad precedent and is a proverbial
> can
> >> of
> >> > worms.
> >> >
> >> > Gary
> >> >
> >> > On Sun, Dec 19, 2021, 17:55 Matt Sicker <bo...@gmail.com> wrote:
> >> >
> >> >> The alternative is to polish the 1.x compatibility in 2.x which is
> both
> >> >> actively maintained and much easier to get releases published. Then
> >> users
> >> >> on 1.x can more easily upgrade to 2.x. I can almost guarantee that
> >> >> regardless of how many warnings we add to a potential 1.x release,
> we’ll
> >> >> get inundated with CVE reports, bug reports, and email, all related
> >> solely
> >> >> to 1.x which none of us wish to maintain (especially given most of us
> >> >> weren’t even involved in 1.x back when it was in development).
> >> >> --
> >> >> Matt Sicker
> >> >>
> >> >> > On Dec 19, 2021, at 16:48, Vladimir Sitnikov <
> >> >> sitnikov.vladimir@gmail.com> wrote:
> >> >> >
> >> >> > Matt>but at least one release using the normal ASF release
> >> requirements
> >> >> is
> >> >> > required to graduate.
> >> >> >
> >> >> > Thanks for the reminder, and I am sure preparing the release won't
> be
> >> an
> >> >> > issue. I refactored release scripts for both Calcite and JMeter,
> and
> >> I am
> >> >> > sure log4j 1.x is doable.
> >> >> >
> >> >> >> compared to the alternatives discussed in this thread.
> >> >> >
> >> >> > I must be missing the alternarives.
> >> >> > Can you please highlight them?
> >> >> >
> >> >> > There were multiple suggestions and various PRs from external
> >> >> contributora,
> >> >> > yet the committers respond with vaugue messages.
> >> >> >
> >> >> > The code must be buildable, so moving to Git, and adding GitHub CI
> is
> >> the
> >> >> > mandatory step.
> >> >> > Of course, the existing PMC members and committers might have
> >> opinions on
> >> >> > the way to fix the issues, however I see no reasons for the team to
> >> deny
> >> >> > Git.
> >> >> >
> >> >> > The migration to Git consumes absolutely no resources from
> committers,
> >> >> > except a couple of +1 votes.
> >> >> >
> >> >> > Unfortunately, even a trivial improvement like Git is ignored by
> >> Logging
> >> >> > PMC.
> >> >> >
> >> >> > So I take Ralph's suggestion to reestablish the new PMC for log4j
> 1.x
> >> >> > seriously.
> >> >> >
> >> >> > Vladimir
> >> >>
> >> >>
> >>
>
Re: Log4J 1.x progress, pull request(s), plans
Posted by Vladimir Sitnikov <si...@gmail.com>.
Gary>If you manage your Maven (for example) POM properly,
Gary>and you assemble a distribution you'll only end up with the latest
version.
Then I don't truly understand what did you mean by mentioning "Jar hell".
I claim that removal of NTEventLogAppender can't cause "jar hell"
because people either keep using 1.2.17 or upgrade to 1.2.18.
You said: "We cannot break binary compatibility, that would create a bigger
mess: Jar hell"
What I say is that if people end up with *both* 1.2.17 and 1.2.18
on the classpath (e.g. failing to manually replace jars in all the places),
they would be screwed no matter how we try keep the compatibility.
That is why removing a rarely used class is not a showstopper.
All in all, it looks like Leo has already fixed the compilation of
the native code, so the discussion of "removal NTEventLogAppender"
is not that important.
Vladimir
Re: Log4J 1.x progress, pull request(s), plans
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Dec 23, 2021 at 8:48 AM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> Gary,
>
> If someone manages to have **both** log4j-1.2.17.jar **and**
> log4j-1.2.18.jar
> on the same classpath, nothing can help them. Really.
> Binary compatibility can't heal that.
>
You're confusing managing a classpath manually with having a dependency
tool do it for you. If you manage your Maven (for example) POM properly,
and you assemble a distribution you'll only end up with the latest version.
Gary
> Even if 1.2.18 was fully binary compatible, adding both jars to the
> classpath
> would blow the system anyway.
>
> In other words, I suggest the following message for NTEventLogAppender
> users:
> "sorry, if you use NTEventLogAppender you might have to skip 1.2.18 version
> or replace NT appender with others"
>
> We can't make 100% of the planet happy.
> For instance, I am sure releasing 1.2.18 makes the log4j2 team greatly
> unhappy no matter what.
>
> If we weigh "spend months on trying to build, sign and test
> NTEventLogAppender" vs
> "release 1.2.18 and say sorry to NTEventLogAppender users",
> I would go for dropping NT* (at least, as a temporary solution).
>
> Vladimir
>
Re: Log4J 1.x progress, pull request(s), plans
Posted by Vladimir Sitnikov <si...@gmail.com>.
Gary,
If someone manages to have **both** log4j-1.2.17.jar **and**
log4j-1.2.18.jar
on the same classpath, nothing can help them. Really.
Binary compatibility can't heal that.
Even if 1.2.18 was fully binary compatible, adding both jars to the
classpath
would blow the system anyway.
In other words, I suggest the following message for NTEventLogAppender
users:
"sorry, if you use NTEventLogAppender you might have to skip 1.2.18 version
or replace NT appender with others"
We can't make 100% of the planet happy.
For instance, I am sure releasing 1.2.18 makes the log4j2 team greatly
unhappy no matter what.
If we weigh "spend months on trying to build, sign and test
NTEventLogAppender" vs
"release 1.2.18 and say sorry to NTEventLogAppender users",
I would go for dropping NT* (at least, as a temporary solution).
Vladimir
Re: Log4J 1.x progress, pull request(s), plans
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Dec 23, 2021 at 8:31 AM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> >Would - in this case - an 1.2.18 with a NoOp NTEventLogAppender be OK?
>
> I am sure 1.2.18 with NoOp (or even throwing NTEventLogAppender unless a
> silence system property is set)
> appender would be more than enough for 1.2.18
>
> If the appender is not used in the wild, we are ok.
> If somebody still uses the appender, they would have an opportunity to
> mention it.
> If somebody would want to resurrect NTEventLogAppender, we could add it as
> a new "module" (==separate jar file).
>
> At any point in time, users have an option to keep using 1.2.17 that they
> used for ages.
>
In actuality, that is not the case. When you deal with large stacks,
transitive dependencies often bring in different versions of the same
artifact from completely different branches of your dependency tree,
*especially* with low-level libraries like... logging, which is why it is
critical to provide binary compatibility.
Gary
> So removing NTEventLogAppender is not really bad, and there's always an
> option to re-introduce it.
>
> Vladimir
>
Re: Log4J 1.x progress, pull request(s), plans
Posted by Vladimir Sitnikov <si...@gmail.com>.
>Would - in this case - an 1.2.18 with a NoOp NTEventLogAppender be OK?
I am sure 1.2.18 with NoOp (or even throwing NTEventLogAppender unless a
silence system property is set)
appender would be more than enough for 1.2.18
If the appender is not used in the wild, we are ok.
If somebody still uses the appender, they would have an opportunity to
mention it.
If somebody would want to resurrect NTEventLogAppender, we could add it as
a new "module" (==separate jar file).
At any point in time, users have an option to keep using 1.2.17 that they
used for ages.
So removing NTEventLogAppender is not really bad, and there's always an
option to re-introduce it.
Vladimir
Re: Log4J 1.x progress, pull request(s), plans
Posted by Christian Grobmeier <gr...@apache.org>.
On Thu, Dec 23, 2021, at 14:05, Gary Gregory wrote:
> One of the difficulties was likely related to building the Windows DLLs
> for
> using the Windows Event Log Appender (
> https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/nt/NTEventLogAppender.html).
> I remember that being challenging. I can't recall if we signed the DLLs
> like we might do for Apache Commons Daemons Windows binaries. Another
> hurdle.
Correct, the DLL is even in the codebase.
https://github.com/apache/logging-log4j1/blob/trunk/NTEventLogAppender.amd64.dll
If we would remove that Appender, it would be much easier to build, when I remember correctly.
Would - in this case - an 1.2.18 with a NoOp NTEventLogAppender be OK?
>
> FWIW, my opinion has been to NOT resurrect 1.x and put our energies into
> improving the 1.2 bridge and configuration file support we already have in
> 2.x. That said, if we decides to move forward with 1.2.18, I'll help.
>
> No matter what, it needs to be a decision made carefully and not in haste.
>
+1
> Gary
>
> On Thu, Dec 23, 2021 at 7:56 AM Christian Grobmeier <gr...@apache.org>
> wrote:
>
>> Hello
>>
>> I have been the person cutting the 1.2.17 release and what I remember was
>> it was a super hard build. I had to install some VMs because there were
>> weird dependencies to this build. Building it fully will not be easy, but I
>> can also look into some mails whatever I found from that time.
>> Here is some build info.:
>> https://github.com/apache/logging-log4j1/blob/trunk/INSTALL
>> Some unit tests only run with a Windows VM
>>
>> It would be easier to remove some components, but BC is broken then.
>>
>> We told people in August 2015 this is EOL. I am honestly surprised that we
>> discuss a new release after 7 years. To my understanding the JMSAppender
>> issue is not as critical (just don't configure it). If a reconfiguration of
>> system is not on the cards, I wonder if upgrading from 1.2.17 to 1.2.18 is.
>>
>> That said i don't think we should resurrect it.
>>
>> If somebody really wants to work on, I also don't think we should go
>> through the incubator. We can do this using the normal processes and apply
>> patches, vote on new committers etc.
>>
>> My 2 cents.
>>
>> Christian
>>
>>
>> On Mon, Dec 20, 2021, at 01:36, Gary Gregory wrote:
>> > Improving legacy compatibility is what I've been pushing. I agree with
>> > Matt. IMO resurrecting 1.x sets a bad precedent and is a proverbial can
>> of
>> > worms.
>> >
>> > Gary
>> >
>> > On Sun, Dec 19, 2021, 17:55 Matt Sicker <bo...@gmail.com> wrote:
>> >
>> >> The alternative is to polish the 1.x compatibility in 2.x which is both
>> >> actively maintained and much easier to get releases published. Then
>> users
>> >> on 1.x can more easily upgrade to 2.x. I can almost guarantee that
>> >> regardless of how many warnings we add to a potential 1.x release, we’ll
>> >> get inundated with CVE reports, bug reports, and email, all related
>> solely
>> >> to 1.x which none of us wish to maintain (especially given most of us
>> >> weren’t even involved in 1.x back when it was in development).
>> >> --
>> >> Matt Sicker
>> >>
>> >> > On Dec 19, 2021, at 16:48, Vladimir Sitnikov <
>> >> sitnikov.vladimir@gmail.com> wrote:
>> >> >
>> >> > Matt>but at least one release using the normal ASF release
>> requirements
>> >> is
>> >> > required to graduate.
>> >> >
>> >> > Thanks for the reminder, and I am sure preparing the release won't be
>> an
>> >> > issue. I refactored release scripts for both Calcite and JMeter, and
>> I am
>> >> > sure log4j 1.x is doable.
>> >> >
>> >> >> compared to the alternatives discussed in this thread.
>> >> >
>> >> > I must be missing the alternarives.
>> >> > Can you please highlight them?
>> >> >
>> >> > There were multiple suggestions and various PRs from external
>> >> contributora,
>> >> > yet the committers respond with vaugue messages.
>> >> >
>> >> > The code must be buildable, so moving to Git, and adding GitHub CI is
>> the
>> >> > mandatory step.
>> >> > Of course, the existing PMC members and committers might have
>> opinions on
>> >> > the way to fix the issues, however I see no reasons for the team to
>> deny
>> >> > Git.
>> >> >
>> >> > The migration to Git consumes absolutely no resources from committers,
>> >> > except a couple of +1 votes.
>> >> >
>> >> > Unfortunately, even a trivial improvement like Git is ignored by
>> Logging
>> >> > PMC.
>> >> >
>> >> > So I take Ralph's suggestion to reestablish the new PMC for log4j 1.x
>> >> > seriously.
>> >> >
>> >> > Vladimir
>> >>
>> >>
>>
Re: Log4J 1.x progress, pull request(s), plans
Posted by Gary Gregory <ga...@gmail.com>.
One of the difficulties was likely related to building the Windows DLLs for
using the Windows Event Log Appender (
https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/nt/NTEventLogAppender.html).
I remember that being challenging. I can't recall if we signed the DLLs
like we might do for Apache Commons Daemons Windows binaries. Another
hurdle.
FWIW, my opinion has been to NOT resurrect 1.x and put our energies into
improving the 1.2 bridge and configuration file support we already have in
2.x. That said, if we decides to move forward with 1.2.18, I'll help.
No matter what, it needs to be a decision made carefully and not in haste.
Gary
On Thu, Dec 23, 2021 at 7:56 AM Christian Grobmeier <gr...@apache.org>
wrote:
> Hello
>
> I have been the person cutting the 1.2.17 release and what I remember was
> it was a super hard build. I had to install some VMs because there were
> weird dependencies to this build. Building it fully will not be easy, but I
> can also look into some mails whatever I found from that time.
> Here is some build info.:
> https://github.com/apache/logging-log4j1/blob/trunk/INSTALL
> Some unit tests only run with a Windows VM
>
> It would be easier to remove some components, but BC is broken then.
>
> We told people in August 2015 this is EOL. I am honestly surprised that we
> discuss a new release after 7 years. To my understanding the JMSAppender
> issue is not as critical (just don't configure it). If a reconfiguration of
> system is not on the cards, I wonder if upgrading from 1.2.17 to 1.2.18 is.
>
> That said i don't think we should resurrect it.
>
> If somebody really wants to work on, I also don't think we should go
> through the incubator. We can do this using the normal processes and apply
> patches, vote on new committers etc.
>
> My 2 cents.
>
> Christian
>
>
> On Mon, Dec 20, 2021, at 01:36, Gary Gregory wrote:
> > Improving legacy compatibility is what I've been pushing. I agree with
> > Matt. IMO resurrecting 1.x sets a bad precedent and is a proverbial can
> of
> > worms.
> >
> > Gary
> >
> > On Sun, Dec 19, 2021, 17:55 Matt Sicker <bo...@gmail.com> wrote:
> >
> >> The alternative is to polish the 1.x compatibility in 2.x which is both
> >> actively maintained and much easier to get releases published. Then
> users
> >> on 1.x can more easily upgrade to 2.x. I can almost guarantee that
> >> regardless of how many warnings we add to a potential 1.x release, we’ll
> >> get inundated with CVE reports, bug reports, and email, all related
> solely
> >> to 1.x which none of us wish to maintain (especially given most of us
> >> weren’t even involved in 1.x back when it was in development).
> >> --
> >> Matt Sicker
> >>
> >> > On Dec 19, 2021, at 16:48, Vladimir Sitnikov <
> >> sitnikov.vladimir@gmail.com> wrote:
> >> >
> >> > Matt>but at least one release using the normal ASF release
> requirements
> >> is
> >> > required to graduate.
> >> >
> >> > Thanks for the reminder, and I am sure preparing the release won't be
> an
> >> > issue. I refactored release scripts for both Calcite and JMeter, and
> I am
> >> > sure log4j 1.x is doable.
> >> >
> >> >> compared to the alternatives discussed in this thread.
> >> >
> >> > I must be missing the alternarives.
> >> > Can you please highlight them?
> >> >
> >> > There were multiple suggestions and various PRs from external
> >> contributora,
> >> > yet the committers respond with vaugue messages.
> >> >
> >> > The code must be buildable, so moving to Git, and adding GitHub CI is
> the
> >> > mandatory step.
> >> > Of course, the existing PMC members and committers might have
> opinions on
> >> > the way to fix the issues, however I see no reasons for the team to
> deny
> >> > Git.
> >> >
> >> > The migration to Git consumes absolutely no resources from committers,
> >> > except a couple of +1 votes.
> >> >
> >> > Unfortunately, even a trivial improvement like Git is ignored by
> Logging
> >> > PMC.
> >> >
> >> > So I take Ralph's suggestion to reestablish the new PMC for log4j 1.x
> >> > seriously.
> >> >
> >> > Vladimir
> >>
> >>
>
Re: Log4J 1.x progress, pull request(s), plans
Posted by Christian Grobmeier <gr...@apache.org>.
Hello
I have been the person cutting the 1.2.17 release and what I remember was it was a super hard build. I had to install some VMs because there were weird dependencies to this build. Building it fully will not be easy, but I can also look into some mails whatever I found from that time.
Here is some build info.:
https://github.com/apache/logging-log4j1/blob/trunk/INSTALL
Some unit tests only run with a Windows VM
It would be easier to remove some components, but BC is broken then.
We told people in August 2015 this is EOL. I am honestly surprised that we discuss a new release after 7 years. To my understanding the JMSAppender issue is not as critical (just don't configure it). If a reconfiguration of system is not on the cards, I wonder if upgrading from 1.2.17 to 1.2.18 is.
That said i don't think we should resurrect it.
If somebody really wants to work on, I also don't think we should go through the incubator. We can do this using the normal processes and apply patches, vote on new committers etc.
My 2 cents.
Christian
On Mon, Dec 20, 2021, at 01:36, Gary Gregory wrote:
> Improving legacy compatibility is what I've been pushing. I agree with
> Matt. IMO resurrecting 1.x sets a bad precedent and is a proverbial can of
> worms.
>
> Gary
>
> On Sun, Dec 19, 2021, 17:55 Matt Sicker <bo...@gmail.com> wrote:
>
>> The alternative is to polish the 1.x compatibility in 2.x which is both
>> actively maintained and much easier to get releases published. Then users
>> on 1.x can more easily upgrade to 2.x. I can almost guarantee that
>> regardless of how many warnings we add to a potential 1.x release, we’ll
>> get inundated with CVE reports, bug reports, and email, all related solely
>> to 1.x which none of us wish to maintain (especially given most of us
>> weren’t even involved in 1.x back when it was in development).
>> --
>> Matt Sicker
>>
>> > On Dec 19, 2021, at 16:48, Vladimir Sitnikov <
>> sitnikov.vladimir@gmail.com> wrote:
>> >
>> > Matt>but at least one release using the normal ASF release requirements
>> is
>> > required to graduate.
>> >
>> > Thanks for the reminder, and I am sure preparing the release won't be an
>> > issue. I refactored release scripts for both Calcite and JMeter, and I am
>> > sure log4j 1.x is doable.
>> >
>> >> compared to the alternatives discussed in this thread.
>> >
>> > I must be missing the alternarives.
>> > Can you please highlight them?
>> >
>> > There were multiple suggestions and various PRs from external
>> contributora,
>> > yet the committers respond with vaugue messages.
>> >
>> > The code must be buildable, so moving to Git, and adding GitHub CI is the
>> > mandatory step.
>> > Of course, the existing PMC members and committers might have opinions on
>> > the way to fix the issues, however I see no reasons for the team to deny
>> > Git.
>> >
>> > The migration to Git consumes absolutely no resources from committers,
>> > except a couple of +1 votes.
>> >
>> > Unfortunately, even a trivial improvement like Git is ignored by Logging
>> > PMC.
>> >
>> > So I take Ralph's suggestion to reestablish the new PMC for log4j 1.x
>> > seriously.
>> >
>> > Vladimir
>>
>>
Re: Log4J 1.x progress, pull request(s), plans
Posted by Gary Gregory <ga...@gmail.com>.
Improving legacy compatibility is what I've been pushing. I agree with
Matt. IMO resurrecting 1.x sets a bad precedent and is a proverbial can of
worms.
Gary
On Sun, Dec 19, 2021, 17:55 Matt Sicker <bo...@gmail.com> wrote:
> The alternative is to polish the 1.x compatibility in 2.x which is both
> actively maintained and much easier to get releases published. Then users
> on 1.x can more easily upgrade to 2.x. I can almost guarantee that
> regardless of how many warnings we add to a potential 1.x release, we’ll
> get inundated with CVE reports, bug reports, and email, all related solely
> to 1.x which none of us wish to maintain (especially given most of us
> weren’t even involved in 1.x back when it was in development).
> --
> Matt Sicker
>
> > On Dec 19, 2021, at 16:48, Vladimir Sitnikov <
> sitnikov.vladimir@gmail.com> wrote:
> >
> > Matt>but at least one release using the normal ASF release requirements
> is
> > required to graduate.
> >
> > Thanks for the reminder, and I am sure preparing the release won't be an
> > issue. I refactored release scripts for both Calcite and JMeter, and I am
> > sure log4j 1.x is doable.
> >
> >> compared to the alternatives discussed in this thread.
> >
> > I must be missing the alternarives.
> > Can you please highlight them?
> >
> > There were multiple suggestions and various PRs from external
> contributora,
> > yet the committers respond with vaugue messages.
> >
> > The code must be buildable, so moving to Git, and adding GitHub CI is the
> > mandatory step.
> > Of course, the existing PMC members and committers might have opinions on
> > the way to fix the issues, however I see no reasons for the team to deny
> > Git.
> >
> > The migration to Git consumes absolutely no resources from committers,
> > except a couple of +1 votes.
> >
> > Unfortunately, even a trivial improvement like Git is ignored by Logging
> > PMC.
> >
> > So I take Ralph's suggestion to reestablish the new PMC for log4j 1.x
> > seriously.
> >
> > Vladimir
>
>
Re: Log4J 1.x progress, pull request(s), plans
Posted by Matt Sicker <bo...@gmail.com>.
The alternative is to polish the 1.x compatibility in 2.x which is both actively maintained and much easier to get releases published. Then users on 1.x can more easily upgrade to 2.x. I can almost guarantee that regardless of how many warnings we add to a potential 1.x release, we’ll get inundated with CVE reports, bug reports, and email, all related solely to 1.x which none of us wish to maintain (especially given most of us weren’t even involved in 1.x back when it was in development).
--
Matt Sicker
> On Dec 19, 2021, at 16:48, Vladimir Sitnikov <si...@gmail.com> wrote:
>
> Matt>but at least one release using the normal ASF release requirements is
> required to graduate.
>
> Thanks for the reminder, and I am sure preparing the release won't be an
> issue. I refactored release scripts for both Calcite and JMeter, and I am
> sure log4j 1.x is doable.
>
>> compared to the alternatives discussed in this thread.
>
> I must be missing the alternarives.
> Can you please highlight them?
>
> There were multiple suggestions and various PRs from external contributora,
> yet the committers respond with vaugue messages.
>
> The code must be buildable, so moving to Git, and adding GitHub CI is the
> mandatory step.
> Of course, the existing PMC members and committers might have opinions on
> the way to fix the issues, however I see no reasons for the team to deny
> Git.
>
> The migration to Git consumes absolutely no resources from committers,
> except a couple of +1 votes.
>
> Unfortunately, even a trivial improvement like Git is ignored by Logging
> PMC.
>
> So I take Ralph's suggestion to reestablish the new PMC for log4j 1.x
> seriously.
>
> Vladimir
Re: Log4J 1.x progress, pull request(s), plans
Posted by Vladimir Sitnikov <si...@gmail.com>.
>Wouldn’t enabling issues imply that issues can be filed for an EOL
component?
You can configure a filter to delete the mails automatically.
On the other hand, it would be nice to know if there are issues like memory
leak.
I do not see a strong need for issue tracker yet. I just wanted to clarify
that adding github issues is a no-brainer.
Vladimir
Re: Log4J 1.x progress, pull request(s), plans
Posted by Matt Sicker <bo...@gmail.com>.
Wouldn’t enabling issues imply that issues can be filed for an EOL component? I don’t see the difference between enabling issues and writing them to /dev/null besides unnecessary emails.
--
Matt Sicker
> On Dec 19, 2021, at 17:23, Vladimir Sitnikov <si...@gmail.com> wrote:
>
>> reactivate Bugzilla or create a Jira for Log4j 1, movie it to GitHub, etc.
>
> "Moving to GitHub" is a no-op, as the current git mirror is ok.
> Bugzilla and JIRA are not needed. GitHub Issues can be activated via single
> line in asf.yml
>
> All this is trivial thanks to the infra team.
>
> Vladimir
Re: Log4J 1.x progress, pull request(s), plans
Posted by Vladimir Sitnikov <si...@gmail.com>.
>reactivate Bugzilla or create a Jira for Log4j 1, movie it to GitHub, etc.
"Moving to GitHub" is a no-op, as the current git mirror is ok.
Bugzilla and JIRA are not needed. GitHub Issues can be activated via single
line in asf.yml
All this is trivial thanks to the infra team.
Vladimir
Re: Log4J 1.x progress, pull request(s), plans
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Dec 19, 2021, at 3:48 PM, Vladimir Sitnikov <si...@gmail.com> wrote:
>
> Matt>but at least one release using the normal ASF release requirements is
> required to graduate.
>
> Thanks for the reminder, and I am sure preparing the release won't be an
> issue. I refactored release scripts for both Calcite and JMeter, and I am
> sure log4j 1.x is doable.
>
>> compared to the alternatives discussed in this thread.
>
> I must be missing the alternarives.
> Can you please highlight them?
The only thing I heard was that the original request was to release 1.2.18 with the minimum changes to address security issues. Then the project would go dormant again.
With this approach it doesn’t seem worth it to reactivate Bugzilla or create a Jira for Log4j 1, movie it to GitHub, etc.
Ralph
>
> There were multiple suggestions and various PRs from external contributora,
> yet the committers respond with vaugue messages.
>
> The code must be buildable, so moving to Git, and adding GitHub CI is the
> mandatory step.
> Of course, the existing PMC members and committers might have opinions on
> the way to fix the issues, however I see no reasons for the team to deny
> Git.
>
> The migration to Git consumes absolutely no resources from committers,
> except a couple of +1 votes.
>
> Unfortunately, even a trivial improvement like Git is ignored by Logging
> PMC.
>
> So I take Ralph's suggestion to reestablish the new PMC for log4j 1.x
> seriously.
>
> Vladimir
Re: Log4J 1.x progress, pull request(s), plans
Posted by Vladimir Sitnikov <si...@gmail.com>.
Matt>but at least one release using the normal ASF release requirements is
required to graduate.
Thanks for the reminder, and I am sure preparing the release won't be an
issue. I refactored release scripts for both Calcite and JMeter, and I am
sure log4j 1.x is doable.
>compared to the alternatives discussed in this thread.
I must be missing the alternarives.
Can you please highlight them?
There were multiple suggestions and various PRs from external contributora,
yet the committers respond with vaugue messages.
The code must be buildable, so moving to Git, and adding GitHub CI is the
mandatory step.
Of course, the existing PMC members and committers might have opinions on
the way to fix the issues, however I see no reasons for the team to deny
Git.
The migration to Git consumes absolutely no resources from committers,
except a couple of +1 votes.
Unfortunately, even a trivial improvement like Git is ignored by Logging
PMC.
So I take Ralph's suggestion to reestablish the new PMC for log4j 1.x
seriously.
Vladimir
Re: Log4J 1.x progress, pull request(s), plans
Posted by Gary Gregory <ga...@gmail.com>.
I think PDFBox and/or POI did something like that with XML Beans.
Gary
On Sun, Dec 19, 2021 at 5:10 PM Matt Sicker <bo...@gmail.com> wrote:
>
> I thought there was some old XML library that was resurrected here at Apache because other PMCs were still using it as a dependency. That might have been more so related to the Attic.
>
> Anyways, as can be seen already, making non-controversial changes to 1.x that both the PMC and our users could accept could turn out to be fairly difficult, especially compared to the level of effort remaining in 2.x to ensure our 1.x backward compatibility support is further polished. I haven’t looked closely at 1.x (beyond some recent checks to see if the JNDI issue was exploitable there, too) in a few years, and even then it had a lot of technical debt to pay off simply related to the build environment and release process. It’s one thing to patch a class and throw a jar into the ever expanding repository that is Maven Central, but it’s a larger effort to publish an Apache release.
>
> Here are some resources about what’s required for a release along with some reference material that’s applicable for any Apache project:
> * https://www.apache.org/legal/release-policy.html <https://www.apache.org/legal/release-policy.html>
> * https://infra.apache.org/release-distribution.html <https://infra.apache.org/release-distribution.html>
> * https://infra.apache.org/release-publishing.html <https://infra.apache.org/release-publishing.html>
> * https://infra.apache.org/release-signing.html <https://infra.apache.org/release-signing.html>
>
> Note that the release requirements for ASF projects cannot be left out. There are less strict release requirements when going through the Incubator, but at least one release using the normal ASF release requirements is required to graduate.
>
> Please take these ASF requirements in mind when considering the amount of work remaining to be done to even get 1.x back into a releasable state compared to the alternatives discussed in this thread.
>
> --
> Matt Sicker
>
> > On Dec 19, 2021, at 15:58, Gary Gregory <ga...@gmail.com> wrote:
> >
> > WRT words, IIRC Apache only has top-level projects (for example,
> > Apache Logging Services, Apache Commons, Apache HttpComponents),
> > within that you can have components, not other projects, for example,
> > Apache Log4j, Apache Commons IO, Apache HttpComponents HttpCore.
> >
> > Gary
> >
> > On Sun, Dec 19, 2021 at 4:29 PM Ralph Goers <ra...@dslextreme.com> wrote:
> >>
> >> The Logging Services project is an “umbrella” project that manages all the logging projects, including Log4j 1.x.
> >> We would not be in favor of having Log4j 1.x become a new standalone PMC.
> >>
> >> But yes, any Logging Services PMC member can veto a code change in any of the sub-projects.
> >> I don’t know that it has ever happened.
> >>
> >> Ralph
> >>
> >>> On Dec 19, 2021, at 2:13 PM, Vladimir Sitnikov <si...@gmail.com> wrote:
> >>>
> >>>> All new ASF projects go through the incubator. Sub-projects don’t have to
> >>> but when an entirely new community is being
> >>>
> >>> I'm a member of PMC Calcite and JMeter, however, I have not submitted
> >>> projects to the incubator yet.
> >>>
> >>>> Once graduated the podling
> >>> PMC members would become part of the Logging Services PMC.
> >>>
> >>> Does that mean the current members of Logging Services PMC could veto code
> >>> changes in the "new" log4j1?
> >>> That sounds strange, and it defeats the reason to re-establish the new set
> >>> of PMC members for log4j 1.x
> >>>
> >>> Vladimir
> >>
>
Re: Log4J 1.x progress, pull request(s), plans
Posted by Matt Sicker <bo...@gmail.com>.
I thought there was some old XML library that was resurrected here at Apache because other PMCs were still using it as a dependency. That might have been more so related to the Attic.
Anyways, as can be seen already, making non-controversial changes to 1.x that both the PMC and our users could accept could turn out to be fairly difficult, especially compared to the level of effort remaining in 2.x to ensure our 1.x backward compatibility support is further polished. I haven’t looked closely at 1.x (beyond some recent checks to see if the JNDI issue was exploitable there, too) in a few years, and even then it had a lot of technical debt to pay off simply related to the build environment and release process. It’s one thing to patch a class and throw a jar into the ever expanding repository that is Maven Central, but it’s a larger effort to publish an Apache release.
Here are some resources about what’s required for a release along with some reference material that’s applicable for any Apache project:
* https://www.apache.org/legal/release-policy.html <https://www.apache.org/legal/release-policy.html>
* https://infra.apache.org/release-distribution.html <https://infra.apache.org/release-distribution.html>
* https://infra.apache.org/release-publishing.html <https://infra.apache.org/release-publishing.html>
* https://infra.apache.org/release-signing.html <https://infra.apache.org/release-signing.html>
Note that the release requirements for ASF projects cannot be left out. There are less strict release requirements when going through the Incubator, but at least one release using the normal ASF release requirements is required to graduate.
Please take these ASF requirements in mind when considering the amount of work remaining to be done to even get 1.x back into a releasable state compared to the alternatives discussed in this thread.
--
Matt Sicker
> On Dec 19, 2021, at 15:58, Gary Gregory <ga...@gmail.com> wrote:
>
> WRT words, IIRC Apache only has top-level projects (for example,
> Apache Logging Services, Apache Commons, Apache HttpComponents),
> within that you can have components, not other projects, for example,
> Apache Log4j, Apache Commons IO, Apache HttpComponents HttpCore.
>
> Gary
>
> On Sun, Dec 19, 2021 at 4:29 PM Ralph Goers <ra...@dslextreme.com> wrote:
>>
>> The Logging Services project is an “umbrella” project that manages all the logging projects, including Log4j 1.x.
>> We would not be in favor of having Log4j 1.x become a new standalone PMC.
>>
>> But yes, any Logging Services PMC member can veto a code change in any of the sub-projects.
>> I don’t know that it has ever happened.
>>
>> Ralph
>>
>>> On Dec 19, 2021, at 2:13 PM, Vladimir Sitnikov <si...@gmail.com> wrote:
>>>
>>>> All new ASF projects go through the incubator. Sub-projects don’t have to
>>> but when an entirely new community is being
>>>
>>> I'm a member of PMC Calcite and JMeter, however, I have not submitted
>>> projects to the incubator yet.
>>>
>>>> Once graduated the podling
>>> PMC members would become part of the Logging Services PMC.
>>>
>>> Does that mean the current members of Logging Services PMC could veto code
>>> changes in the "new" log4j1?
>>> That sounds strange, and it defeats the reason to re-establish the new set
>>> of PMC members for log4j 1.x
>>>
>>> Vladimir
>>
Re: Log4J 1.x progress, pull request(s), plans
Posted by Gary Gregory <ga...@gmail.com>.
WRT words, IIRC Apache only has top-level projects (for example,
Apache Logging Services, Apache Commons, Apache HttpComponents),
within that you can have components, not other projects, for example,
Apache Log4j, Apache Commons IO, Apache HttpComponents HttpCore.
Gary
On Sun, Dec 19, 2021 at 4:29 PM Ralph Goers <ra...@dslextreme.com> wrote:
>
> The Logging Services project is an “umbrella” project that manages all the logging projects, including Log4j 1.x.
> We would not be in favor of having Log4j 1.x become a new standalone PMC.
>
> But yes, any Logging Services PMC member can veto a code change in any of the sub-projects.
> I don’t know that it has ever happened.
>
> Ralph
>
> > On Dec 19, 2021, at 2:13 PM, Vladimir Sitnikov <si...@gmail.com> wrote:
> >
> >> All new ASF projects go through the incubator. Sub-projects don’t have to
> > but when an entirely new community is being
> >
> > I'm a member of PMC Calcite and JMeter, however, I have not submitted
> > projects to the incubator yet.
> >
> >> Once graduated the podling
> > PMC members would become part of the Logging Services PMC.
> >
> > Does that mean the current members of Logging Services PMC could veto code
> > changes in the "new" log4j1?
> > That sounds strange, and it defeats the reason to re-establish the new set
> > of PMC members for log4j 1.x
> >
> > Vladimir
>
Re: Log4J 1.x progress, pull request(s), plans
Posted by Ralph Goers <ra...@dslextreme.com>.
The Logging Services project is an “umbrella” project that manages all the logging projects, including Log4j 1.x.
We would not be in favor of having Log4j 1.x become a new standalone PMC.
But yes, any Logging Services PMC member can veto a code change in any of the sub-projects.
I don’t know that it has ever happened.
Ralph
> On Dec 19, 2021, at 2:13 PM, Vladimir Sitnikov <si...@gmail.com> wrote:
>
>> All new ASF projects go through the incubator. Sub-projects don’t have to
> but when an entirely new community is being
>
> I'm a member of PMC Calcite and JMeter, however, I have not submitted
> projects to the incubator yet.
>
>> Once graduated the podling
> PMC members would become part of the Logging Services PMC.
>
> Does that mean the current members of Logging Services PMC could veto code
> changes in the "new" log4j1?
> That sounds strange, and it defeats the reason to re-establish the new set
> of PMC members for log4j 1.x
>
> Vladimir
Re: Log4J 1.x progress, pull request(s), plans
Posted by Vladimir Sitnikov <si...@gmail.com>.
>All new ASF projects go through the incubator. Sub-projects don’t have to
but when an entirely new community is being
I'm a member of PMC Calcite and JMeter, however, I have not submitted
projects to the incubator yet.
> Once graduated the podling
PMC members would become part of the Logging Services PMC.
Does that mean the current members of Logging Services PMC could veto code
changes in the "new" log4j1?
That sounds strange, and it defeats the reason to re-establish the new set
of PMC members for log4j 1.x
Vladimir
Re: Log4J 1.x progress, pull request(s), plans
Posted by Ralph Goers <ra...@dslextreme.com>.
I should have said, you would have to publish at least one release in the incubator to qualify to graduate. Once graduated the podling
PMC members would become part of the Logging Services PMC.
Ralph
> On Dec 19, 2021, at 2:00 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> The process is that a form gets filled out in the Incubator’s Confluence wiki. The form lists the proposed podling PMC members.
> It isn’t strange at all for the people to then send an email to the incubator list. If that is what you are contemplating then you
> should start at https://incubator.apache.org/.https://incubator.apache.org/cookbook/ provides a good walkthrough of the process.
>
> All new ASF projects go through the incubator. Sub-projects don’t have to but when an entirely new community is being
> developed who are probably unfamiliar with the workings of the ASF it is recommended.
>
> Ralph
>
>> On Dec 19, 2021, at 1:33 PM, Vladimir Sitnikov <si...@gmail.com> wrote:
>>
>> Ralph>if you want to resurrect the project then this really should go
>> through
>> Ralph>the ASF incubator with the Logging Services project as the sponsor
>>
>> Ralph,
>> Do you think you know similar cases?
>> Could you please suggest the procedure for resurrection?
>>
>> I guess it would look strange if I submit a mail to the incubator saying I
>> want to take over log4j 1.x.
>>
>> Vladimir
>
Re: Log4J 1.x progress, pull request(s), plans
Posted by Ralph Goers <ra...@dslextreme.com>.
The process is that a form gets filled out in the Incubator’s Confluence wiki. The form lists the proposed podling PMC members.
It isn’t strange at all for the people to then send an email to the incubator list. If that is what you are contemplating then you
should start at https://incubator.apache.org/.https://incubator.apache.org/cookbook/ provides a good walkthrough of the process.
All new ASF projects go through the incubator. Sub-projects don’t have to but when an entirely new community is being
developed who are probably unfamiliar with the workings of the ASF it is recommended.
Ralph
> On Dec 19, 2021, at 1:33 PM, Vladimir Sitnikov <si...@gmail.com> wrote:
>
> Ralph>if you want to resurrect the project then this really should go
> through
> Ralph>the ASF incubator with the Logging Services project as the sponsor
>
> Ralph,
> Do you think you know similar cases?
> Could you please suggest the procedure for resurrection?
>
> I guess it would look strange if I submit a mail to the incubator saying I
> want to take over log4j 1.x.
>
> Vladimir
Re: Log4J 1.x progress, pull request(s), plans
Posted by Vladimir Sitnikov <si...@gmail.com>.
Ralph>if you want to resurrect the project then this really should go
through
Ralph>the ASF incubator with the Logging Services project as the sponsor
Ralph,
Do you think you know similar cases?
Could you please suggest the procedure for resurrection?
I guess it would look strange if I submit a mail to the incubator saying I
want to take over log4j 1.x.
Vladimir
Re: Log4J 1.x progress, pull request(s), plans
Posted by Leo Simons <ma...@leosimons.com>.
Hey,
On Sat, Dec 18, 2021 at 1:52 PM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> >Similarly to set up git(hub) requires a PMC member.
> >Hopefully the [VOTE] on that is revisited and then someone sets it up.
>
> Would you please express your opinion on "[VOTE] Move log4j 1.x from SVN to
> Git..." thread?
> Non-committers can vote.
>
Sure, done :). I prefer to [VOTE] as little as possible, and instead to
seek out, understand and resolve all advice/concerns/objections so that
when a vote is finally needed it's easy / pro-forma.
> Frankly speaking, it is really sad that committers and PMCs are silent
> regarding 1.x security.
>
Hmm, is that what you think people are doing? I look at it very differently.
Several 2.x committers have already chimed in with advice and suggestions
and have even said they were willing to do some of the work.
For me the real sadness here is in the very distant past, back in Jakarta
days, when fights happened and many of the log4j 1.x people left.
Asking the people who volunteered to pick up the pieces and clean up to now
do more than they already did is asking a lot.
Meanwhile I think the team here has done really well suddenly facing
tremendous pressure.
Given the state of the internet, I think their focus on 2.x is super needed
and smart.
I can only imagine how much work happens behind the scenes.
I've been quite positively surprised by the amount of attention that's
still been available for 1.x.
So I'm not sad, I'm grateful!
> If all the current members for PMC logging are indifferent regarding 1.x,
> can there be a new PMC for log4j 1.x?
>
Hrmpf. Do you have any idea how much *work* that is? :)
I have less than zero interest in that.
> >In that case we can put an unofficial release somewhere on github.
>
> I think there are many forks that fix 1.x security, especially, in-house
> ones.
> For instance, https://github.com/JetBrains/intellij-deps-log4j
I know so! Here's a couple interesting forks:
*fork commits*
https://github.com/sebasjm/log4j 136
https://github.com/albfernandez/log4j 44
https://github.com/DarkPhoenixs/log4j-patch 32
https://github.com/lsimons/log4j 30 (itsa me! :-) )
https://github.com/rj08-97/log4j 22
https://github.com/vinzlercodes/log4j 22
https://github.com/clhsieh211/log4j 17
https://github.com/appian/log4j/tree/appian_1_2_17 14
*not bothered to fork commits*
https://github.com/ltslog/ltslog 12
https://github.com/JetBrains/intellij-deps-log4j 2
Tragedy of the github commons: many find these days it's much easier to
fork than to contribute.
There's a lot of build fixes, some performance tuning, some small features,
and a lot of deleting code due to security.
Didn't really see anyone do their utmost to preserve compatibility beyond
what they need for themselves.
I'm going to guess for the 100 public ones there are at least a 1000
in-company forks like this that you don't see.
Cheers,
Leo
Re: Log4J 1.x progress, pull request(s), plans
Posted by Matt Sicker <bo...@gmail.com>.
Chainsaw was extracted into its own repository, so those changes are probably ok at least.
—
Matt Sicker
> On Dec 18, 2021, at 12:17, Leo Simons <ma...@leosimons.com> wrote:
>
> On Sat, Dec 18, 2021 at 5:32 PM Leo Simons <ma...@leosimons.com> wrote:
>
>>> On Sat, Dec 18, 2021 at 3:34 PM Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>
>>> If you delete anything that is public or protected, you will break
>>> binary compatibility, and that's a no-go IMO.
>>
>>
>> Agree. I hope we can get clirr (or something like it) back to work, to
>> prove binary compatibility.
>>
>
> Sorry for the extra mail but I'm excited, I just learned japicmp exists :-)
>
> "Someone" wrote a nice blog post on how to use it...
>
>
> https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
>
> So the setup was easy to steal...
>
> https://github.com/apache/commons-lang/blob/master/pom.xml
> https://github.com/apache/commons-parent/blob/master/pom.xml
>
> Leads to question: how do we feel about removal of .lf5 (javax.swing
> logging) and .chainsaw (java.awt logging) packages?
>
> It's an old change that was already on the trunk.
>
>
> https://github.com/apache/log4j/pull/16/commits/5c29c4048b4860aa7f6a86420f20208459e6c22c#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R251
>
> I can understand why it was made.
>
>
> Cheers,
>
>
> Leo
Re: Log4J 1.x progress, pull request(s), plans
Posted by Gary Gregory <ga...@gmail.com>.
A hard -1
Thank you for pitching in but this PR completely breaks major blocks
of functionality.
I see comments like "Changed in 1.2.18+ to complain about its use and
do nothing else." for the JDBC Appender, Telnet Appender,
ExternallyRolledFileAppender, JMS Appender, JMX, and more! 140 files
changed? You might want to do one PR per CVE/issue.
The PR says "binary compatible" but that's only because the code has
been gutted which will break applications left and right.
This PR is so far out-of-bounds that I have a hard time finding where to start.
1.x is End-Of-Life.
If we do ANYTHING, it would be to address CVEs. We have CVE:
CVE-2019-1757. We also have discussed security in the JMS Appender. So
that would be two changes to do in two PRs IMO. This PR deals with
neither in a meaningful manner.
I see a disconnect between the email and the PR:
"So as requested I've made a conservative fully binary compatible version of
all the build changes and security fixes, patches are on a new pull request
at"
This PR contains ZERO security fixes, it just removes code. For me
"conservative" means the least amount of changes, not gutting the
code, changing 140 files, and breaking applications with no
alternative.
"Trying to have solid network code in 1.x while having it also be binary
compatible is way too much work"
So you've gutted the code because doing real fixes is "too much work".
There you have it I guess.
I am not endorsing a 1.2.18 release but if there was consensus on the
PMC for resurrection it should be ONLY to address IMO CVE-2019-1757
and the JMS Appender using the same techniques we used in 2.x.
I'll leave it to each person to decide what is "too much work", just
note that it took 6 of us working almost full time to work on 2.15.0,
2.16.0, 2.17.0, and 2.12.2.
Keep in mind that this is a low-level library that must be a drop-in
replacement in all settings from the largest enterprise to a hobbyist.
Hence our choices of remedies in 2.x.
Gary
On Sun, Dec 19, 2021 at 8:14 AM Leo Simons <ma...@leosimons.com> wrote:
>
> Hey folks,
>
> So as requested I've made a conservative fully binary compatible version of
> all the build changes and security fixes, patches are on a new pull request
> at
>
> https://github.com/apache/log4j/pull/17
>
> On Sat, Dec 18, 2021 at 7:30 PM Gary Gregory <ga...@gmail.com> wrote:
>
> > Again, you cannot break binary compatibility in a minor release. That's a
> > show stopper.
> >
>
> Ok, if that's what you want....hope the new approach is acceptable on
> review.
>
> I will note most of log4j 1.2 was not nearly so strict (semantic versioning
> not being a standard 'thing' back then), as you can also tell from the
> plans to drop chainsaw from 1.2.18 and so on...but it does make sense as a
> policy in 2021 I guess.
>
> Depending on what the consensus approach eventually becomes, you could also
> pick up from an earlier commit, for example taking all the build fixes but
> writing your own java code changes.
>
>
> > This discussion IMO should ONLY be about mitigation of CVEs and that means
> > porting the idea of the fixes from 2.x to 1.x. This 1.x component is EOL. I
> > say "idea" because the code bases for 1.x and 2.x are completely different.
> >
>
> As I wrote before I don't agree with this part of the strategy you propose.
> I understand it in the abstract but I do not think it is realistic. 2.x has
> a lot of network code that is a lot better and more modern than is in 1.x.
> Trying to have solid network code in 1.x while having it also be binary
> compatible is way too much work, and even if you manage to then test that
> things are behavior-compatible at runtime...there'd then be a real risk of
> unintended regressions there.
>
> I think the mitigation strategy that's on the PR now is good enough(tm) to
> help many people.
>
> From my side, I am now out of time to work on this for the next couple of
> weeks. I may try and check my e-mail a bit next week, but no promises. I
> hope this is in a good state so others in the community can pick things up
> from there!
>
>
> Meanwhile, take care, cheers,
>
>
> Leo
Re: Log4J 1.x progress, pull request(s), plans
Posted by Leo Simons <ma...@leosimons.com>.
Hey folks,
So as requested I've made a conservative fully binary compatible version of
all the build changes and security fixes, patches are on a new pull request
at
https://github.com/apache/log4j/pull/17
On Sat, Dec 18, 2021 at 7:30 PM Gary Gregory <ga...@gmail.com> wrote:
> Again, you cannot break binary compatibility in a minor release. That's a
> show stopper.
>
Ok, if that's what you want....hope the new approach is acceptable on
review.
I will note most of log4j 1.2 was not nearly so strict (semantic versioning
not being a standard 'thing' back then), as you can also tell from the
plans to drop chainsaw from 1.2.18 and so on...but it does make sense as a
policy in 2021 I guess.
Depending on what the consensus approach eventually becomes, you could also
pick up from an earlier commit, for example taking all the build fixes but
writing your own java code changes.
> This discussion IMO should ONLY be about mitigation of CVEs and that means
> porting the idea of the fixes from 2.x to 1.x. This 1.x component is EOL. I
> say "idea" because the code bases for 1.x and 2.x are completely different.
>
As I wrote before I don't agree with this part of the strategy you propose.
I understand it in the abstract but I do not think it is realistic. 2.x has
a lot of network code that is a lot better and more modern than is in 1.x.
Trying to have solid network code in 1.x while having it also be binary
compatible is way too much work, and even if you manage to then test that
things are behavior-compatible at runtime...there'd then be a real risk of
unintended regressions there.
I think the mitigation strategy that's on the PR now is good enough(tm) to
help many people.
From my side, I am now out of time to work on this for the next couple of
weeks. I may try and check my e-mail a bit next week, but no promises. I
hope this is in a good state so others in the community can pick things up
from there!
Meanwhile, take care, cheers,
Leo
Re: Log4J 1.x progress, pull request(s), plans
Posted by Andrew Marlow <ma...@gmail.com>.
Hello everyone,
Please look at the RedHat CVE report made concerning log4j-v1 some time
ago: https://access.redhat.com/security/cve/cve-2017-5645
RedHat made the fix, presumably for the sake of RedHat users that for one
reason or another were stuck on log4j-v1. Once log4j-1 has moved to git
then if any fixes are made or considered then I think the one already done
by RedHat should be adopted. This is their fix for /cve-2017-5645 and is
quite a small patch.
On Sat, 18 Dec 2021 at 18:30, Gary Gregory <ga...@gmail.com> wrote:
> Again, you cannot break binary compatibility in a minor release. That's a
> show stopper.
>
> This discussion IMO should ONLY be about mitigation of CVEs and that means
> porting the idea of the fixes from 2.x to 1.x. This 1.x component is EOL. I
> say "idea" because the code bases for 1.x and 2.x are completely different.
>
> From my point of view, any other edits are DOA. I am focusing my 1.x
> efforts in improving compatibility in 2.x for 1.2 behavior in the
> log4j-1.2-api module. Towards this goal please see the 1.2 bridge fixes in
> 2.17.0.
>
> If you want to help 1.x users in the best manner possible, IMO, help them
> move forward to 2.x by helping on the mailing lists, Jira, GitHub, Slack,
> there is no shortage of work to be done.
>
> Ty,
> Gary
>
> On Sat, Dec 18, 2021, 13:17 Leo Simons <ma...@leosimons.com> wrote:
>
> > On Sat, Dec 18, 2021 at 5:32 PM Leo Simons <ma...@leosimons.com> wrote:
> >
> > > On Sat, Dec 18, 2021 at 3:34 PM Gary Gregory <ga...@gmail.com>
> > > wrote:
> > >
> > >> If you delete anything that is public or protected, you will break
> > >> binary compatibility, and that's a no-go IMO.
> > >
> > >
> > > Agree. I hope we can get clirr (or something like it) back to work, to
> > > prove binary compatibility.
> > >
> >
> > Sorry for the extra mail but I'm excited, I just learned japicmp exists
> :-)
> >
> > "Someone" wrote a nice blog post on how to use it...
> >
> >
> >
> >
> https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
> >
> > So the setup was easy to steal...
> >
> > https://github.com/apache/commons-lang/blob/master/pom.xml
> > https://github.com/apache/commons-parent/blob/master/pom.xml
> >
> > Leads to question: how do we feel about removal of .lf5 (javax.swing
> > logging) and .chainsaw (java.awt logging) packages?
> >
> > It's an old change that was already on the trunk.
> >
> >
> >
> >
> https://github.com/apache/log4j/pull/16/commits/5c29c4048b4860aa7f6a86420f20208459e6c22c#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R251
> >
> > I can understand why it was made.
> >
> >
> > Cheers,
> >
> >
> > Leo
> >
>
--
Regards,
Andrew Marlow
http://www.andrewpetermarlow.co.uk
Re: Log4J 1.x progress, pull request(s), plans
Posted by Gary Gregory <ga...@gmail.com>.
Again, you cannot break binary compatibility in a minor release. That's a
show stopper.
This discussion IMO should ONLY be about mitigation of CVEs and that means
porting the idea of the fixes from 2.x to 1.x. This 1.x component is EOL. I
say "idea" because the code bases for 1.x and 2.x are completely different.
From my point of view, any other edits are DOA. I am focusing my 1.x
efforts in improving compatibility in 2.x for 1.2 behavior in the
log4j-1.2-api module. Towards this goal please see the 1.2 bridge fixes in
2.17.0.
If you want to help 1.x users in the best manner possible, IMO, help them
move forward to 2.x by helping on the mailing lists, Jira, GitHub, Slack,
there is no shortage of work to be done.
Ty,
Gary
On Sat, Dec 18, 2021, 13:17 Leo Simons <ma...@leosimons.com> wrote:
> On Sat, Dec 18, 2021 at 5:32 PM Leo Simons <ma...@leosimons.com> wrote:
>
> > On Sat, Dec 18, 2021 at 3:34 PM Gary Gregory <ga...@gmail.com>
> > wrote:
> >
> >> If you delete anything that is public or protected, you will break
> >> binary compatibility, and that's a no-go IMO.
> >
> >
> > Agree. I hope we can get clirr (or something like it) back to work, to
> > prove binary compatibility.
> >
>
> Sorry for the extra mail but I'm excited, I just learned japicmp exists :-)
>
> "Someone" wrote a nice blog post on how to use it...
>
>
>
> https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
>
> So the setup was easy to steal...
>
> https://github.com/apache/commons-lang/blob/master/pom.xml
> https://github.com/apache/commons-parent/blob/master/pom.xml
>
> Leads to question: how do we feel about removal of .lf5 (javax.swing
> logging) and .chainsaw (java.awt logging) packages?
>
> It's an old change that was already on the trunk.
>
>
>
> https://github.com/apache/log4j/pull/16/commits/5c29c4048b4860aa7f6a86420f20208459e6c22c#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R251
>
> I can understand why it was made.
>
>
> Cheers,
>
>
> Leo
>
Re: Log4J 1.x progress, pull request(s), plans
Posted by Leo Simons <ma...@leosimons.com>.
On Sat, Dec 18, 2021 at 5:32 PM Leo Simons <ma...@leosimons.com> wrote:
> On Sat, Dec 18, 2021 at 3:34 PM Gary Gregory <ga...@gmail.com>
> wrote:
>
>> If you delete anything that is public or protected, you will break
>> binary compatibility, and that's a no-go IMO.
>
>
> Agree. I hope we can get clirr (or something like it) back to work, to
> prove binary compatibility.
>
Sorry for the extra mail but I'm excited, I just learned japicmp exists :-)
"Someone" wrote a nice blog post on how to use it...
https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
So the setup was easy to steal...
https://github.com/apache/commons-lang/blob/master/pom.xml
https://github.com/apache/commons-parent/blob/master/pom.xml
Leads to question: how do we feel about removal of .lf5 (javax.swing
logging) and .chainsaw (java.awt logging) packages?
It's an old change that was already on the trunk.
https://github.com/apache/log4j/pull/16/commits/5c29c4048b4860aa7f6a86420f20208459e6c22c#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R251
I can understand why it was made.
Cheers,
Leo
Re: Log4J 1.x progress, pull request(s), plans
Posted by Leo Simons <ma...@leosimons.com>.
Hey Gary,
On Sat, Dec 18, 2021 at 3:34 PM Gary Gregory <ga...@gmail.com> wrote:
> If you delete anything that is public or protected, you will break
> binary compatibility, and that's a no-go IMO.
Agree. I hope we can get clirr (or something like it) back to work, to
prove binary compatibility.
Perhaps with one exception:
Initially what I did for the classes that start up servers is to disable
their behavior.
But Vladimir convinced me it's better to remove them.
Some reasoning:
* it's easier to understand and easier to audit.
* it also matches common advice across the internet to delete things from
the jars.
* very unlikely someone subclassed.
* if they did subclass, it is very unlikely an upgrade to 1.2.18 makes
sense for them.
* if people are running these daemons, we can't really hope to secure it
for them, so they can stay on 1.2.17.
So I caved and on the draft PR I now deleted net.JMSSink / net.SocketServer
/ net.SimpleSocketServer / jmx.Agent.
https://github.com/apache/log4j/pull/16/commits/911fc233742c1c85668c22873b8b913623d91680
https://github.com/apache/log4j/pull/16/commits/246b0439a779575f2bae573e55dd4cad077e2ca0
What do you think, are these ok exceptions to you?
Technically it's easy enough to do either way but I can't do both :)
> If are going to really
> want to release anything, you'll want to disable JNDI by default and
> add an enablement property as we did for 2.17.0.
>
Hmm, I wasn't really intending to allow re-enabling JNDI, instead I just
disabled JMS completely:
https://github.com/lsimons/log4j/blob/2021-security-fixes/src/main/java/org/apache/log4j/net/JMSAppender.java#L44
Some reasoning:
* If you're ok with doing your log4j security 'around' the package (i.e.
solid network firewall / trusted sources & targets, conservative config
file), in practice you can just stay on 1.2.17.
* If not, then 1.2.18 can just disable everything 'worrisome' for you.
* If you need more flexibility / want a maintained secure way to do
JMS/SMTP/etc: upgrade to 2.x!
Does that make sense?
Cheers,
Leo
Re: Log4J 1.x progress, pull request(s), plans
Posted by Gary Gregory <ga...@gmail.com>.
If you delete anything that is public or protected, you will break
binary compatibility, and that's a no-go IMO. If are going to really
want to release anything, you'll want to disable JNDI by default and
add an enablement property as we did for 2.17.0.
Gary
On Sat, Dec 18, 2021 at 9:13 AM Robert Middleton <os...@gmail.com> wrote:
>
> I can do the security release if something exists in a good state.
> The reasoning for me is that there are still many applications that
> exist that have not upgraded, even though it's been 6+ years.
>
> If it is binary compatible as well, that makes upgrades easy(I'm
> thinking of a case where you have an application from a 3rd party that
> you need to use but the vendor won't update because it's EOL or
> something like that). Dropping the new JAR in should be good enough
> to mitigate security vulnerabilities for those applications.
>
> -Robert Middleton
>
> On Sat, Dec 18, 2021 at 7:52 AM Vladimir Sitnikov
> <si...@gmail.com> wrote:
> >
> > >From my side what I volunteered for is to propose changes that should go in
> > >that fix for review.
> >
> > Thank you.
> >
> > >Similarly to set up git(hub) requires a PMC member.
> > >Hopefully the [VOTE] on that is revisited and then someone sets it up.
> >
> > Would you please express your opinion on "[VOTE] Move log4j 1.x from SVN to
> > Git..." thread?
> > Non-committers can vote.
> >
> > Frankly speaking, it is really sad that committers and PMCs are silent
> > regarding 1.x security.
> > The Git mirror already exists, making SVN read-only is trivial.
> > I do not believe it takes that much effort to vote for the migration.
> > I do not really understand the reasons behind vetoing the move to Git.
> > Why veto the security fix for log4j 1.x in case you are not interested in
> > 1.x development?
> >
> > If all the current members for PMC logging are indifferent regarding 1.x,
> > can there be a new PMC for log4j 1.x?
> >
> > >In that case we can put an unofficial release somewhere on github.
> >
> > I think there are many forks that fix 1.x security, especially, in-house
> > ones.
> > For instance, https://github.com/JetBrains/intellij-deps-log4j
> >
> > Vladimir
Re: Log4J 1.x progress, pull request(s), plans
Posted by Robert Middleton <os...@gmail.com>.
I can do the security release if something exists in a good state.
The reasoning for me is that there are still many applications that
exist that have not upgraded, even though it's been 6+ years.
If it is binary compatible as well, that makes upgrades easy(I'm
thinking of a case where you have an application from a 3rd party that
you need to use but the vendor won't update because it's EOL or
something like that). Dropping the new JAR in should be good enough
to mitigate security vulnerabilities for those applications.
-Robert Middleton
On Sat, Dec 18, 2021 at 7:52 AM Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> >From my side what I volunteered for is to propose changes that should go in
> >that fix for review.
>
> Thank you.
>
> >Similarly to set up git(hub) requires a PMC member.
> >Hopefully the [VOTE] on that is revisited and then someone sets it up.
>
> Would you please express your opinion on "[VOTE] Move log4j 1.x from SVN to
> Git..." thread?
> Non-committers can vote.
>
> Frankly speaking, it is really sad that committers and PMCs are silent
> regarding 1.x security.
> The Git mirror already exists, making SVN read-only is trivial.
> I do not believe it takes that much effort to vote for the migration.
> I do not really understand the reasons behind vetoing the move to Git.
> Why veto the security fix for log4j 1.x in case you are not interested in
> 1.x development?
>
> If all the current members for PMC logging are indifferent regarding 1.x,
> can there be a new PMC for log4j 1.x?
>
> >In that case we can put an unofficial release somewhere on github.
>
> I think there are many forks that fix 1.x security, especially, in-house
> ones.
> For instance, https://github.com/JetBrains/intellij-deps-log4j
>
> Vladimir
Re: Log4J 1.x progress, pull request(s), plans
Posted by Vladimir Sitnikov <si...@gmail.com>.
>From my side what I volunteered for is to propose changes that should go in
>that fix for review.
Thank you.
>Similarly to set up git(hub) requires a PMC member.
>Hopefully the [VOTE] on that is revisited and then someone sets it up.
Would you please express your opinion on "[VOTE] Move log4j 1.x from SVN to
Git..." thread?
Non-committers can vote.
Frankly speaking, it is really sad that committers and PMCs are silent
regarding 1.x security.
The Git mirror already exists, making SVN read-only is trivial.
I do not believe it takes that much effort to vote for the migration.
I do not really understand the reasons behind vetoing the move to Git.
Why veto the security fix for log4j 1.x in case you are not interested in
1.x development?
If all the current members for PMC logging are indifferent regarding 1.x,
can there be a new PMC for log4j 1.x?
>In that case we can put an unofficial release somewhere on github.
I think there are many forks that fix 1.x security, especially, in-house
ones.
For instance, https://github.com/JetBrains/intellij-deps-log4j
Vladimir
Re: Log4J 1.x progress, pull request(s), plans
Posted by Leo Simons <ma...@leosimons.com>.
Hey,
TL;DR: I have no intention to contribute anything but a security fix, and
I don't think there's anyone who thinks differently.
I'll provide a patch but won't/can't make the official release.
From my side what I volunteered for is to propose changes that should go in
that fix for review.
I guess I'm proposing more changes than you expected!
Must be my internal quality bar: IMO an apache release should (primarily)
be a source release that's easy to (re)build and test.
That's been quite a bit of effort.
By comparison, getting rid of some old java code is much easier :)
Since I'm not a committer or PMC member, I can't really manage a release or
publish the website.
(I probably also won't have time for it next week.)
Someone else would have to step up for that.
Similarly to set up git(hub) requires a PMC member.
Hopefully the [VOTE] on that is revisited and then someone sets it up.
Otherwise we can figure out how to coerce a [PATCH] mail out of git to
apply to svn.
I hope we can get PR(s) into a good enough shape to convince the PMC to
accept the changes and make a release.
But if the PMC ultimately cannot or does not want to do that, no harm
done, no work lost.
In that case we can put an unofficial release somewhere on github.
Personally I think for end users that will be less clear/convenient, but I
also think reasonable people can have different perspectives there.
Fortunately apache doesn't always require full consensus, just enough +1s
and enough volunteers, so I have some hope :)
Cheers,
Leo
On Fri, Dec 17, 2021 at 7:28 PM Ralph Goers <ra...@dslextreme.com>
wrote:
> I am still questioning the plan. If you are planning on just creating a
> security release
> and then having the project go back to its coffin then I am not sure why
> all the tooling
> is needed. OTOH, if you want to resurrect the project then this really
> should go through
> the ASF incubator with the Logging Services project as the sponsor.
>
> Ralph
>
> > On Dec 17, 2021, at 10:24 AM, Leo Simons <ma...@leosimons.com> wrote:
> >
> > Hey,
> >
> > Progress today
> > ----
> > As mentioned I made a draft PR for the branch I'm working on:
> >
> > https://github.com/apache/log4j/pull/16
> >
> > My main progress today was to get the unit test suite working reliably
> > (dozens of tests were disabled because they had flaky results), and then
> to
> > get build and test to run reliably on a bunch of different
> JDK/toolchain/OS
> > combos, using github actions for CI:
> >
> > https://github.com/lsimons/log4j/actions/runs/1593087224
> >
> > I also read through the SyslogAppender which I thought about
> > disabling completely, but have opted for a stern warning instead for any
> > configs that write to non-localhost.
> >
> > In the net package, SMTPAppender still needs more of an opinion on what
> to
> > do exactly (see some notes on the e-mail thread Tony started).
> >
> > Other PRs
> > ----
> > I've also cherry-picked a couple of reasonable PRs into the branch I'm
> > working on:
> >
> > https://github.com/apache/log4j/pull/13 (by Geertjan Wielenga)
> > https://github.com/apache/log4j/pull/10 (by Vincent Privat)
> >
> > For the remaining ones I went through them and wrote suggestions for
> what I
> > think should happen, which amounts to: all PRs except for the new #16
> > should be closed. (I don't have permission to click "Close" of course.)
> >
> > Integration tests
> > ----
> > Existing test suite took so much time that I didn't get around to
> starting
> > on any integration tests yet.
> >
> > I would like to have some fixture projects set up into which to
> auto-inject
> > different problematic config files and 1.x libraries, assert there is a
> > problem, replace with the new library, assert it's ok.
> >
> > Wondering if it's easy to make it all a bit sysadmin friendly (i.e. shell
> > scripts / docker / ...), so you don't need to know java to see the
> problem
> > or to verify the solution.
> >
> > ...and then it'd make sense to me to have another git repo.
> >
> >
> > Cheers,
> >
> >
> > Leo
>
>
Re: Log4J 1.x progress, pull request(s), plans
Posted by Ralph Goers <ra...@dslextreme.com>.
I am still questioning the plan. If you are planning on just creating a security release
and then having the project go back to its coffin then I am not sure why all the tooling
is needed. OTOH, if you want to resurrect the project then this really should go through
the ASF incubator with the Logging Services project as the sponsor.
Ralph
> On Dec 17, 2021, at 10:24 AM, Leo Simons <ma...@leosimons.com> wrote:
>
> Hey,
>
> Progress today
> ----
> As mentioned I made a draft PR for the branch I'm working on:
>
> https://github.com/apache/log4j/pull/16
>
> My main progress today was to get the unit test suite working reliably
> (dozens of tests were disabled because they had flaky results), and then to
> get build and test to run reliably on a bunch of different JDK/toolchain/OS
> combos, using github actions for CI:
>
> https://github.com/lsimons/log4j/actions/runs/1593087224
>
> I also read through the SyslogAppender which I thought about
> disabling completely, but have opted for a stern warning instead for any
> configs that write to non-localhost.
>
> In the net package, SMTPAppender still needs more of an opinion on what to
> do exactly (see some notes on the e-mail thread Tony started).
>
> Other PRs
> ----
> I've also cherry-picked a couple of reasonable PRs into the branch I'm
> working on:
>
> https://github.com/apache/log4j/pull/13 (by Geertjan Wielenga)
> https://github.com/apache/log4j/pull/10 (by Vincent Privat)
>
> For the remaining ones I went through them and wrote suggestions for what I
> think should happen, which amounts to: all PRs except for the new #16
> should be closed. (I don't have permission to click "Close" of course.)
>
> Integration tests
> ----
> Existing test suite took so much time that I didn't get around to starting
> on any integration tests yet.
>
> I would like to have some fixture projects set up into which to auto-inject
> different problematic config files and 1.x libraries, assert there is a
> problem, replace with the new library, assert it's ok.
>
> Wondering if it's easy to make it all a bit sysadmin friendly (i.e. shell
> scripts / docker / ...), so you don't need to know java to see the problem
> or to verify the solution.
>
> ...and then it'd make sense to me to have another git repo.
>
>
> Cheers,
>
>
> Leo