You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Ralph Goers <ra...@dslextreme.com> on 2021/12/23 06:34:02 UTC
New Log4j 1 repo
I have cloned the read-only log4j repo to https://github.com/apache/logging-log4j1.
I have followed the build instructions and had to modify the javadoc plugin to not fail on errors. Now it fails in the site plugin.
If someone else wants to take this on I would suggest the first PR should just to the pom.xml file to get the build working as is.
Ralph
Re: New Log4j 1 repo
Posted by Xeno Amess <xe...@gmail.com>.
Do read only mean we cannot give pull request？
Then how can I help you clean the pom correct...
XenoAmess
________________________________
From: Ralph Goers <ra...@dslextreme.com>
Sent: Thursday, December 23, 2021 2:34:02 PM
To: dev@logging.apache.org <de...@logging.apache.org>
Subject: New Log4j 1 repo
I have cloned the read-only log4j repo to https://github.com/apache/logging-log4j1.
I have followed the build instructions and had to modify the javadoc plugin to not fail on errors. Now it fails in the site plugin.
If someone else wants to take this on I would suggest the first PR should just to the pom.xml file to get the build working as is.
Ralph
Re: New Log4j 1 repo
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Dec 23, 2021 at 8:43 AM Carter Kozak <ck...@ckozak.net> wrote:
> I’d rather use a name like ‘main’ or ‘develop’ for inclusivity (across all
> our projects).
>
We use 'develop' and 'master' w/i the same repos at work so that would not
help my brain :-) but I am OK changing the name to something else than
'trunk' as long as we do it consistently across all Log4j repos; it would
be best to be consistent across Logging Services project repos. Otherwise,
I know I'll fat finger something ;-)
Gary
> -ck
>
> > On Dec 23, 2021, at 08:41, Gary Gregory <ga...@gmail.com> wrote:
> >
> > If we use this repo, is everyone OK renaming "trunk" to "master" in
> order
> > to match the branch name of our other repos?
> >
> > Gary
> >
> >> On Thu, Dec 23, 2021 at 1:34 AM Ralph Goers <ralph.goers@dslextreme.com
> >
> >> wrote:
> >>
> >> I have cloned the read-only log4j repo to
> >> https://github.com/apache/logging-log4j1.
> >>
> >> I have followed the build instructions and had to modify the javadoc
> >> plugin to not fail on errors. Now it fails in the site plugin.
> >>
> >> If someone else wants to take this on I would suggest the first PR
> should
> >> just to the pom.xml file to get the build working as is.
> >>
> >> Ralph
> >>
> >>
> >>
>
>
Re: New Log4j 1 repo
Posted by Carter Kozak <ck...@ckozak.net>.
I’d rather use a name like ‘main’ or ‘develop’ for inclusivity (across all our projects).
-ck
> On Dec 23, 2021, at 08:41, Gary Gregory <ga...@gmail.com> wrote:
>
> If we use this repo, is everyone OK renaming "trunk" to "master" in order
> to match the branch name of our other repos?
>
> Gary
>
>> On Thu, Dec 23, 2021 at 1:34 AM Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>> I have cloned the read-only log4j repo to
>> https://github.com/apache/logging-log4j1.
>>
>> I have followed the build instructions and had to modify the javadoc
>> plugin to not fail on errors. Now it fails in the site plugin.
>>
>> If someone else wants to take this on I would suggest the first PR should
>> just to the pom.xml file to get the build working as is.
>>
>> Ralph
>>
>>
>>
Re: New Log4j 1 repo
Posted by Gary Gregory <ga...@gmail.com>.
Cute :-) But... Over at Apache Commons, we just dropped all trunk branches
a long time ago. No renames, it's simpler IMO.
Gary
On Thu, Dec 23, 2021 at 9:57 AM Ralph Goers <ra...@dslextreme.com>
wrote:
> I am planning on creating a branch off the 1.2.17 tag. That branch will be
> named main.
> I will make that the default branch. Then I plan to rename trunk to a nice
> name like
> DEAD-HEAD (GRATEFUL)
>
> Ralph
>
> > On Dec 23, 2021, at 7:20 AM, Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > A name like "version" should only be for tags. Once a version is
> released,
> > it does not make sense to have a branch by that name, but it would be OK
> to
> > have a name for a "maintenance line", as we did with "2.12.x", so here we
> > would have "1.2.x" which is lame IMO because we're ONLY EVER going to
> have
> > 1.2 releases, so it might as well stay in master/main/trunk.
> >
> > Gary
> >
> > On Thu, Dec 23, 2021 at 9:17 AM Gary Gregory <ga...@gmail.com>
> wrote:
> >
> >> WAIT, what? That does not make sense, it's the same bad name we ended up
> >> in with the "2.12" branch instead of "2.12.x".
> >>
> >> Gary
> >>
> >> On Thu, Dec 23, 2021 at 8:50 AM Apache <ra...@dslextreme.com>
> wrote:
> >>
> >>> I was already asked to create a branch off of 1.2.17. It will become
> the
> >>> main branch so trunk can be left alone.
> >>>
> >>> Ralph
> >>>
> >>>> On Dec 23, 2021, at 6:41 AM, Gary Gregory <ga...@gmail.com>
> >>> wrote:
> >>>>
> >>>> If we use this repo, is everyone OK renaming "trunk" to "master" in
> >>> order
> >>>> to match the branch name of our other repos?
> >>>>
> >>>> Gary
> >>>>
> >>>>> On Thu, Dec 23, 2021 at 1:34 AM Ralph Goers <
> >>> ralph.goers@dslextreme.com>
> >>>>> wrote:
> >>>>>
> >>>>> I have cloned the read-only log4j repo to
> >>>>> https://github.com/apache/logging-log4j1.
> >>>>>
> >>>>> I have followed the build instructions and had to modify the javadoc
> >>>>> plugin to not fail on errors. Now it fails in the site plugin.
> >>>>>
> >>>>> If someone else wants to take this on I would suggest the first PR
> >>> should
> >>>>> just to the pom.xml file to get the build working as is.
> >>>>>
> >>>>> Ralph
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
>
>
Re: New Log4j 1 repo
Posted by Ralph Goers <ra...@dslextreme.com>.
I am planning on creating a branch off the 1.2.17 tag. That branch will be named main.
I will make that the default branch. Then I plan to rename trunk to a nice name like
DEAD-HEAD (GRATEFUL)
Ralph
> On Dec 23, 2021, at 7:20 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> A name like "version" should only be for tags. Once a version is released,
> it does not make sense to have a branch by that name, but it would be OK to
> have a name for a "maintenance line", as we did with "2.12.x", so here we
> would have "1.2.x" which is lame IMO because we're ONLY EVER going to have
> 1.2 releases, so it might as well stay in master/main/trunk.
>
> Gary
>
> On Thu, Dec 23, 2021 at 9:17 AM Gary Gregory <ga...@gmail.com> wrote:
>
>> WAIT, what? That does not make sense, it's the same bad name we ended up
>> in with the "2.12" branch instead of "2.12.x".
>>
>> Gary
>>
>> On Thu, Dec 23, 2021 at 8:50 AM Apache <ra...@dslextreme.com> wrote:
>>
>>> I was already asked to create a branch off of 1.2.17. It will become the
>>> main branch so trunk can be left alone.
>>>
>>> Ralph
>>>
>>>> On Dec 23, 2021, at 6:41 AM, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>>
>>>> If we use this repo, is everyone OK renaming "trunk" to "master" in
>>> order
>>>> to match the branch name of our other repos?
>>>>
>>>> Gary
>>>>
>>>>> On Thu, Dec 23, 2021 at 1:34 AM Ralph Goers <
>>> ralph.goers@dslextreme.com>
>>>>> wrote:
>>>>>
>>>>> I have cloned the read-only log4j repo to
>>>>> https://github.com/apache/logging-log4j1.
>>>>>
>>>>> I have followed the build instructions and had to modify the javadoc
>>>>> plugin to not fail on errors. Now it fails in the site plugin.
>>>>>
>>>>> If someone else wants to take this on I would suggest the first PR
>>> should
>>>>> just to the pom.xml file to get the build working as is.
>>>>>
>>>>> Ralph
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
Re: New Log4j 1 repo
Posted by Gary Gregory <ga...@gmail.com>.
A name like "version" should only be for tags. Once a version is released,
it does not make sense to have a branch by that name, but it would be OK to
have a name for a "maintenance line", as we did with "2.12.x", so here we
would have "1.2.x" which is lame IMO because we're ONLY EVER going to have
1.2 releases, so it might as well stay in master/main/trunk.
Gary
On Thu, Dec 23, 2021 at 9:17 AM Gary Gregory <ga...@gmail.com> wrote:
> WAIT, what? That does not make sense, it's the same bad name we ended up
> in with the "2.12" branch instead of "2.12.x".
>
> Gary
>
> On Thu, Dec 23, 2021 at 8:50 AM Apache <ra...@dslextreme.com> wrote:
>
>> I was already asked to create a branch off of 1.2.17. It will become the
>> main branch so trunk can be left alone.
>>
>> Ralph
>>
>> > On Dec 23, 2021, at 6:41 AM, Gary Gregory <ga...@gmail.com>
>> wrote:
>> >
>> > If we use this repo, is everyone OK renaming "trunk" to "master" in
>> order
>> > to match the branch name of our other repos?
>> >
>> > Gary
>> >
>> >> On Thu, Dec 23, 2021 at 1:34 AM Ralph Goers <
>> ralph.goers@dslextreme.com>
>> >> wrote:
>> >>
>> >> I have cloned the read-only log4j repo to
>> >> https://github.com/apache/logging-log4j1.
>> >>
>> >> I have followed the build instructions and had to modify the javadoc
>> >> plugin to not fail on errors. Now it fails in the site plugin.
>> >>
>> >> If someone else wants to take this on I would suggest the first PR
>> should
>> >> just to the pom.xml file to get the build working as is.
>> >>
>> >> Ralph
>> >>
>> >>
>> >>
>>
>>
>>
Re: New Log4j 1 repo
Posted by Gary Gregory <ga...@gmail.com>.
WAIT, what? That does not make sense, it's the same bad name we ended up in
with the "2.12" branch instead of "2.12.x".
Gary
On Thu, Dec 23, 2021 at 8:50 AM Apache <ra...@dslextreme.com> wrote:
> I was already asked to create a branch off of 1.2.17. It will become the
> main branch so trunk can be left alone.
>
> Ralph
>
> > On Dec 23, 2021, at 6:41 AM, Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > If we use this repo, is everyone OK renaming "trunk" to "master" in
> order
> > to match the branch name of our other repos?
> >
> > Gary
> >
> >> On Thu, Dec 23, 2021 at 1:34 AM Ralph Goers <ralph.goers@dslextreme.com
> >
> >> wrote:
> >>
> >> I have cloned the read-only log4j repo to
> >> https://github.com/apache/logging-log4j1.
> >>
> >> I have followed the build instructions and had to modify the javadoc
> >> plugin to not fail on errors. Now it fails in the site plugin.
> >>
> >> If someone else wants to take this on I would suggest the first PR
> should
> >> just to the pom.xml file to get the build working as is.
> >>
> >> Ralph
> >>
> >>
> >>
>
>
>
Re: New Log4j 1 repo
Posted by Apache <ra...@dslextreme.com>.
I was already asked to create a branch off of 1.2.17. It will become the main branch so trunk can be left alone.
Ralph
> On Dec 23, 2021, at 6:41 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> If we use this repo, is everyone OK renaming "trunk" to "master" in order
> to match the branch name of our other repos?
>
> Gary
>
>> On Thu, Dec 23, 2021 at 1:34 AM Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>> I have cloned the read-only log4j repo to
>> https://github.com/apache/logging-log4j1.
>>
>> I have followed the build instructions and had to modify the javadoc
>> plugin to not fail on errors. Now it fails in the site plugin.
>>
>> If someone else wants to take this on I would suggest the first PR should
>> just to the pom.xml file to get the build working as is.
>>
>> Ralph
>>
>>
>>
Re: New Log4j 1 repo
Posted by Gary Gregory <ga...@gmail.com>.
If we use this repo, is everyone OK renaming "trunk" to "master" in order
to match the branch name of our other repos?
Gary
On Thu, Dec 23, 2021 at 1:34 AM Ralph Goers <ra...@dslextreme.com>
wrote:
> I have cloned the read-only log4j repo to
> https://github.com/apache/logging-log4j1.
>
> I have followed the build instructions and had to modify the javadoc
> plugin to not fail on errors. Now it fails in the site plugin.
>
> If someone else wants to take this on I would suggest the first PR should
> just to the pom.xml file to get the build working as is.
>
> Ralph
>
>
>
Re: New Log4j 1 repo
Posted by Gary Gregory <ga...@gmail.com>.
Well done Ralph, I'll take a look today.
Gary
On Thu, Dec 23, 2021, 01:34 Ralph Goers <ra...@dslextreme.com> wrote:
> I have cloned the read-only log4j repo to
> https://github.com/apache/logging-log4j1.
>
> I have followed the build instructions and had to modify the javadoc
> plugin to not fail on errors. Now it fails in the site plugin.
>
> If someone else wants to take this on I would suggest the first PR should
> just to the pom.xml file to get the build working as is.
>
> Ralph
>
>
>
Re: New Log4j 1 repo
Posted by Vladimir Sitnikov <si...@gmail.com>.
Ralph, thank you.
Why did you create a new repository?
AFAIK, infra could reopen the old one on request.
Vladimir
Re: New Log4j 1 repo
Posted by Xeno Amess <xe...@gmail.com>.
understand now. thanks.
XenoAmess
________________________________
From: Apache <ra...@dslextreme.com>
Sent: Thursday, December 23, 2021 2:45:14 PM
To: dev@logging.apache.org <de...@logging.apache.org>
Subject: Re: New Log4j 1 repo
https://github.com/apache/log4j was read-only. The new repo is not.
Ralph
> On Dec 22, 2021, at 11:34 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> I have cloned the read-only log4j repo to https://github.com/apache/logging-log4j1.
>
> I have followed the build instructions and had to modify the javadoc plugin to not fail on errors. Now it fails in the site plugin.
>
> If someone else wants to take this on I would suggest the first PR should just to the pom.xml file to get the build working as is.
>
> Ralph
>
>
Re: New Log4j 1 repo
Posted by Apache <ra...@dslextreme.com>.
https://github.com/apache/log4j was read-only. The new repo is not.
Ralph
> On Dec 22, 2021, at 11:34 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> I have cloned the read-only log4j repo to https://github.com/apache/logging-log4j1.
>
> I have followed the build instructions and had to modify the javadoc plugin to not fail on errors. Now it fails in the site plugin.
>
> If someone else wants to take this on I would suggest the first PR should just to the pom.xml file to get the build working as is.
>
> Ralph
>
>
Re: New Log4j 1 repo
Posted by Apache <ra...@dslextreme.com>.
I have VMWare on my Mac with both Ubuntu and Windows 10. So I should be able to run a build.
Ralph
> On Dec 23, 2021, at 5:59 AM, Christian Grobmeier <gr...@apache.org> wrote:
>
> Hi,
>
>
> On Thu, Dec 23, 2021, at 13:33, Vladimir Sitnikov wrote:
>>> using maven toolchain feature
>>
>> Are toolchains really needed, especially, 1.6 and 1.7?
>> I believe Java "target=1.4" + Java 1.8 would be good enough.
>> If there are javadoc "warnings or errors", we could just suppress it.
>> At the end of the day, making the build 100 times harder by requesting Java
>> 1.6
>> looks like an overkill.
>>
>> I think there's no way to install Java 1.6 on modern macOS.
>
> Correct. I would suggest Docker, if there is a way to install it there.
>
> Here is some more installation instructions:
> https://github.com/apache/logging-log4j1/blob/trunk/INSTALL
>
> For a complete build for a release, one needs to run tests using some DLLs which made it very hard back then.
>
> Christian
>
>
>>
>> Vladimir
>
Re: New Log4j 1 repo
Posted by Christian Grobmeier <gr...@apache.org>.
Hi,
On Thu, Dec 23, 2021, at 13:33, Vladimir Sitnikov wrote:
>>using maven toolchain feature
>
> Are toolchains really needed, especially, 1.6 and 1.7?
> I believe Java "target=1.4" + Java 1.8 would be good enough.
> If there are javadoc "warnings or errors", we could just suppress it.
> At the end of the day, making the build 100 times harder by requesting Java
> 1.6
> looks like an overkill.
>
> I think there's no way to install Java 1.6 on modern macOS.
Correct. I would suggest Docker, if there is a way to install it there.
Here is some more installation instructions:
https://github.com/apache/logging-log4j1/blob/trunk/INSTALL
For a complete build for a release, one needs to run tests using some DLLs which made it very hard back then.
Christian
>
> Vladimir
Re: New Log4j 1 repo
Posted by Leo Simons <ma...@leosimons.com>.
Hey,
I am interested in legacy/vintage core enterprise systems deep inside large
enterprises and governments, where source code changes are out of the
question, that have lit up yellow in security/compliance dashboards due to
the old CVE against log4j 1.2 for years, that now light up as orange due to
all the increased attention to log4j.
There’s some Java 6 installs.
Rule of thumb: when I know of java 6 installs then a poor guy somewhere is
maintaining a system like that on JDK 1.4.
Practically, securing these systems is not hard. But, having dashboards go
green “the easy way” needs an official upstream (or accepted redistributor)
mitigation that is then runbooked and ideally automated.
On the PRs I made you can use -P no-toolchain to build with any modern JDK
that maven+plugins are happy with. Already proven with a working GitHub
actions maven build. What’s so hard?
Could you check if the -P no-toolchain setup works for you on Mac out of
the box? It might also be good to add a patch to switch which build is
default for convenience of the average Mac user.
Cheers,
Leo
On Thu, 23 Dec 2021 at 13:33, Vladimir Sitnikov <si...@gmail.com>
wrote:
> >using maven toolchain feature
>
> Are toolchains really needed, especially, 1.6 and 1.7?
> I believe Java "target=1.4" + Java 1.8 would be good enough.
> If there are javadoc "warnings or errors", we could just suppress it.
> At the end of the day, making the build 100 times harder by requesting Java
> 1.6
> looks like an overkill.
>
> I think there's no way to install Java 1.6 on modern macOS.
>
> Vladimir
>
Re: New Log4j 1 repo
Posted by Vladimir Sitnikov <si...@gmail.com>.
>using maven toolchain feature
Are toolchains really needed, especially, 1.6 and 1.7?
I believe Java "target=1.4" + Java 1.8 would be good enough.
If there are javadoc "warnings or errors", we could just suppress it.
At the end of the day, making the build 100 times harder by requesting Java
1.6
looks like an overkill.
I think there's no way to install Java 1.6 on modern macOS.
Vladimir
Re: New Log4j 1 repo
Posted by Leo Simons <ma...@leosimons.com>.
Hmm my best guess still is the javadoc warning>error. I didn’t think that
started with JDK 8…
The PR I had made for trunk has this fix for it
https://github.com/apache/log4j/pull/16/commits/490255fbe6a3bc729c09be8ff36b6c965029d67c
For the 1.2.17 PR that commit is not there, probably the broken javadoc
came onto trunk after 1.2.17.
True that modern maven needs modern JDK, so setting up a compat build for
1.2.18 involved using maven toolchain feature.
Cheers,
Leo
On Thu, 23 Dec 2021 at 13:18, Apache <ra...@dslextreme.com> wrote:
> Thanks Leo. I was using Java 8 with maven 3 in a Linux VM. I don’t think
> maven 3 runs on Java 6.
>
> Ralph
>
> > On Dec 23, 2021, at 5:11 AM, Leo Simons <ma...@leosimons.com> wrote:
> >
> > On Thu, 23 Dec 2021 at 12:39, Ralph Goers <ra...@dslextreme.com>
> > wrote:
> >
> >> It is still the middle of the night for me so I won’t do anything for
> >> several hours.
> >
> >
> > Whoa, best get some rest! :)
> >
> > I will create the branch but I am curious about the rest. When I ran the
> >> build last night it ran through a bunch of unit tests without any
> problems.
> >
> >
> > The 1.2.17 build as-is has only a short whitelist of tests being run from
> > maven. There are many more tests only set up to run with ant, without
> maven
> > invoking ant.
> >
> > I changed the maven build to run all tests. Then set up a matrix build.
> > Some of the other tests worked out of the box, not all. So then fixed the
> > tests that didn’t work with maven (or JDK 9, or Linux and JDK 11).
> Disabled
> > a couple really flaky ones.
> >
> > It then failed due to javadoc errors.
> >
> >
> > Probably you used JDK9+ where some warnings become errors. I fixed that
> too
> > in a later commit by fixing the javadoc. You can also use older JDK
> (IIRC 6
> > or 7).
> >
> > I just told the plugin not to fail and then it started executing the site
> >> plugin. I tried updating the version but that just caused it to have an
> >> error in the site.xml.
> >
> >
> > Yup, fixing the site was a lot of work!
> >
> > My question is, you said that the build has test failures. Did I not see
> >> them because of the changes after 1.2.17 or is something else going on?
> >
> >
> > I think the summary answer here is “lots is going on”!
> > 1.2.17 partially migrated the build from ant to maven 2, back in 2012.
> > Frankly it wasn’t in so clean a state at time of release.
> > That makes sense since all the plug-in stability in maven really only
> came
> > after maven 3. Back then it was pretty normal to work around plugin
> > regressions every point release…you can see TODO comments in the 1.2.17
> pom
> > about it…
> > ….you may have forgotten the extent of such pain :-). Cleaning it all up
> > was a bunch of explorative surgery!
> >
> > Cheers,
> >
> > Leo
>
>
>
Re: New Log4j 1 repo
Posted by Apache <ra...@dslextreme.com>.
Thanks Leo. I was using Java 8 with maven 3 in a Linux VM. I don’t think maven 3 runs on Java 6.
Ralph
> On Dec 23, 2021, at 5:11 AM, Leo Simons <ma...@leosimons.com> wrote:
>
> On Thu, 23 Dec 2021 at 12:39, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> It is still the middle of the night for me so I won’t do anything for
>> several hours.
>
>
> Whoa, best get some rest! :)
>
> I will create the branch but I am curious about the rest. When I ran the
>> build last night it ran through a bunch of unit tests without any problems.
>
>
> The 1.2.17 build as-is has only a short whitelist of tests being run from
> maven. There are many more tests only set up to run with ant, without maven
> invoking ant.
>
> I changed the maven build to run all tests. Then set up a matrix build.
> Some of the other tests worked out of the box, not all. So then fixed the
> tests that didn’t work with maven (or JDK 9, or Linux and JDK 11). Disabled
> a couple really flaky ones.
>
> It then failed due to javadoc errors.
>
>
> Probably you used JDK9+ where some warnings become errors. I fixed that too
> in a later commit by fixing the javadoc. You can also use older JDK (IIRC 6
> or 7).
>
> I just told the plugin not to fail and then it started executing the site
>> plugin. I tried updating the version but that just caused it to have an
>> error in the site.xml.
>
>
> Yup, fixing the site was a lot of work!
>
> My question is, you said that the build has test failures. Did I not see
>> them because of the changes after 1.2.17 or is something else going on?
>
>
> I think the summary answer here is “lots is going on”!
> 1.2.17 partially migrated the build from ant to maven 2, back in 2012.
> Frankly it wasn’t in so clean a state at time of release.
> That makes sense since all the plug-in stability in maven really only came
> after maven 3. Back then it was pretty normal to work around plugin
> regressions every point release…you can see TODO comments in the 1.2.17 pom
> about it…
> ….you may have forgotten the extent of such pain :-). Cleaning it all up
> was a bunch of explorative surgery!
>
> Cheers,
>
> Leo
Re: New Log4j 1 repo
Posted by Leo Simons <ma...@leosimons.com>.
On Thu, 23 Dec 2021 at 12:39, Ralph Goers <ra...@dslextreme.com>
wrote:
> It is still the middle of the night for me so I won’t do anything for
> several hours.
Whoa, best get some rest! :)
I will create the branch but I am curious about the rest. When I ran the
> build last night it ran through a bunch of unit tests without any problems.
The 1.2.17 build as-is has only a short whitelist of tests being run from
maven. There are many more tests only set up to run with ant, without maven
invoking ant.
I changed the maven build to run all tests. Then set up a matrix build.
Some of the other tests worked out of the box, not all. So then fixed the
tests that didn’t work with maven (or JDK 9, or Linux and JDK 11). Disabled
a couple really flaky ones.
It then failed due to javadoc errors.
Probably you used JDK9+ where some warnings become errors. I fixed that too
in a later commit by fixing the javadoc. You can also use older JDK (IIRC 6
or 7).
I just told the plugin not to fail and then it started executing the site
> plugin. I tried updating the version but that just caused it to have an
> error in the site.xml.
Yup, fixing the site was a lot of work!
My question is, you said that the build has test failures. Did I not see
> them because of the changes after 1.2.17 or is something else going on?
I think the summary answer here is “lots is going on”!
1.2.17 partially migrated the build from ant to maven 2, back in 2012.
Frankly it wasn’t in so clean a state at time of release.
That makes sense since all the plug-in stability in maven really only came
after maven 3. Back then it was pretty normal to work around plugin
regressions every point release…you can see TODO comments in the 1.2.17 pom
about it…
….you may have forgotten the extent of such pain :-). Cleaning it all up
was a bunch of explorative surgery!
Cheers,
Leo
Re: New Log4j 1 repo
Posted by Ralph Goers <ra...@dslextreme.com>.
Leo,
It is still the middle of the night for me so I won’t do anything for several hours. I will create the branch but I am curious about the rest. When I ran the build last night it ran through a bunch of unit tests without any problems. It then failed due to javadoc errors. I just told the plugin not to fail and then it started executing the site plugin. I tried updating the version but that just caused it to have an error in the site.xml.
My question is, you said that the build has test failures. Did I not see them because of the changes after 1.2.17 or is something else going on?
Ralph
> On Dec 23, 2021, at 2:22 AM, Leo Simons <ma...@leosimons.com> wrote:
>
> (On mobile)
>
> Cool.
>
> First I suggest to make a new branch from 1.2.17. Trunk has various stuff
> that’s backwards incompatible. Something like
>
> git checkout -b main v1_0_2_17
> git push -u main
>
> Then go into GitHub settings and make main the default branch.
>
> So then people make PRs against that.
>
> Think someone can take up to a5405370d844fca078c25f66654f929d07b1a922 from
>
> https://github.com/apache/log4j/pull/17 to make a PR to get to a modern
> build.
>
> With some test failures because I got rid of the limited whitelist of unit
> tests. Most of the commits after that set up GitHub actions and fix the
> test suite.
>
> I expect you can safely take everything on that PR17 that is a commit that
> does not start with “fix:” without much discussion.
>
> Each of those “fix:” commits from PR17 should then be a distinct PR and a
> discussion, where based on Gary’s feedback most of them have a -1 against
> them due to dropping functionality.
>
> Instead of or in addition to some of those fixes, a nice alternative
> approach that Vladimir suggested before is to split off the more
> problematic integrations (jdbc,jms,smtp,telnet,plaintext socket) into their
> own mini library jars. Then you can replace log4j-1.2.17.jar with
> log4j-1.2.18.jar and in the rare(r) cases you do need the other stuff you
> add in, say, log4j-jms-1.2.18.jar. Easy to understand, not too much effort.
>
> The third approach, the one Gary suggested, is to backport (the idea of)
> more secure code from 2.x.
>
> Cheers,
>
> Leo
>
>> On Thu, 23 Dec 2021 at 07:34, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>> I have cloned the read-only log4j repo to
>> https://github.com/apache/logging-log4j1.
>>
>> I have followed the build instructions and had to modify the javadoc
>> plugin to not fail on errors. Now it fails in the site plugin.
>>
>> If someone else wants to take this on I would suggest the first PR should
>> just to the pom.xml file to get the build working as is.
>>
>> Ralph
>>
>>
>>
Re: New Log4j 1 repo
Posted by Gary Gregory <ga...@gmail.com>.
Vladimir,
I appreciate your energy and your enthusiasm, I do, but you're going to
have to pick your battles IMO.
I would say we (not but really wearing my PMC hat) have passively agreed
that we can move toward fixing CVEs and potential CVEs in what would be a
1.2.18.
For us to get there and while we are still navigating this storm, means
that we all have to make compromises and make a smooth path for the team,
infra, users. This new repo is part of this smoother path. So, please don't
get caught up in the mechanics, I encourage you to look toward the finish
line.
Allow me to relate what I am seeing in the enterprise and with
organizations that provide professional services that might make this whole
thing moot. As much as I explain the differences between Log4j 1 and 2 and
the different issues that have occurred in both, the path is clear: People
finally understand what end-of-life is and are moving toward Log4j 2. Let's
skip the discussion of the Yossarian-like pickle for people who had already
migrated and stepped into the RCE CVE. As I am advising these various
people, some realize the 1.2 bridge will work fine, others have started
rewriting their configuration in Log4j 2 XML on their own. All of this to
say that, even though 1.2 might be safer within certain bounds, and made
safer in the future, stacks are just moving to 2.x.
HTH,
Gary
On Thu, Dec 23, 2021 at 7:25 AM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> >All logging services Git repos start with logging-.
>
> I'm 100% sure INFRA can rename `apache/log4j` into `apache/logging-log4j1`,
> and it would be transparent for GitHub users.
> GitHub would automatically redirect from apache/log4j to
> apache/logging-log4j1
>
> >Of course you are free to screw around
>
> Just in case you miss:
> * What I really want to do here is to heal log4j 1.x for **everybody**.
> That is why I want to get the canonical repository and the canonical Maven
> coordinates.
> * Of course, for my private applications, I have created and fixed log4j
> 1.x **long ago**.
> I just realized, this "private forks" effort is duplicated all over the
> world,
> and I realized the right thing to do is to fix the official log4j 1.x no
> matter what "Logging PMC thinks of 1.x being EOL"
>
> Vladimir
>
Re: New Log4j 1 repo
Posted by Vladimir Sitnikov <si...@gmail.com>.
>All logging services Git repos start with logging-.
I'm 100% sure INFRA can rename `apache/log4j` into `apache/logging-log4j1`,
and it would be transparent for GitHub users.
GitHub would automatically redirect from apache/log4j to
apache/logging-log4j1
>Of course you are free to screw around
Just in case you miss:
* What I really want to do here is to heal log4j 1.x for **everybody**.
That is why I want to get the canonical repository and the canonical Maven
coordinates.
* Of course, for my private applications, I have created and fixed log4j
1.x **long ago**.
I just realized, this "private forks" effort is duplicated all over the
world,
and I realized the right thing to do is to fix the official log4j 1.x no
matter what "Logging PMC thinks of 1.x being EOL"
Vladimir
Re: New Log4j 1 repo
Posted by Apache <ra...@dslextreme.com>.
From what I can tell that repo could only be “owned” by a TLP named log4j.apache.org. It doesn’t show up on the list of gitbox repos owned by any ASF projects. I believe it is a read-only mirror tied to the sun repo. I asked infra about it in slack and they weren’t quite sure what it is. So rather than hunt that down and make everyone wait I created the new repo. All logging services Git repos start with logging-.
Of course you are free to screw around and try to make something happen with the old repo rather than just getting started.
Ralph
> On Dec 23, 2021, at 4:56 AM, Vladimir Sitnikov <si...@gmail.com> wrote:
>
> Leo>Instead of or in addition to some of those fixes
>
> I would suggest the following (in case you wonder, I might volunteer to do
> ALL of that, so don't assume I just sit and tell others how things should
> be done):
> 1. Use the existing repo https://github.com/apache/log4j instead of a newly
> created one.
> The existing repo is well-known in the community (108 watch, 537 forks, 849
> stars), and it is very strange to drop all that.
> 2. Add GitHub CI so the code at least compiles. I think we should not fix
> everything like javadoc/site/whatever if it takes too much time.
> Having any CI would be way better than nothing.
> 3. Consider existing known CVE fixes (e.g. somewhere there was a mention of
> RedHat fixes for log4j 1.x CVEs).
> It might be easier to apply the fixes before the code is split.
> 4. Consider splitting the code into modules. In practice, there's already a
> branch that does exactly that:
> https://github.com/apache/log4j/tree/log4j12modules/modules
> 5. Release 1.2.18.
> 6. Treat CVEs. For instance, implement hardening in log4j-net or whatever.
> 7. Release 1.2.19
> 8.... see what happens, maybe new PR would appear.
>
> Vladimir
Re: New Log4j 1 repo
Posted by Vladimir Sitnikov <si...@gmail.com>.
Leo>Instead of or in addition to some of those fixes
I would suggest the following (in case you wonder, I might volunteer to do
ALL of that, so don't assume I just sit and tell others how things should
be done):
1. Use the existing repo https://github.com/apache/log4j instead of a newly
created one.
The existing repo is well-known in the community (108 watch, 537 forks, 849
stars), and it is very strange to drop all that.
2. Add GitHub CI so the code at least compiles. I think we should not fix
everything like javadoc/site/whatever if it takes too much time.
Having any CI would be way better than nothing.
3. Consider existing known CVE fixes (e.g. somewhere there was a mention of
RedHat fixes for log4j 1.x CVEs).
It might be easier to apply the fixes before the code is split.
4. Consider splitting the code into modules. In practice, there's already a
branch that does exactly that:
https://github.com/apache/log4j/tree/log4j12modules/modules
5. Release 1.2.18.
6. Treat CVEs. For instance, implement hardening in log4j-net or whatever.
7. Release 1.2.19
8.... see what happens, maybe new PR would appear.
Vladimir
Re: New Log4j 1 repo
Posted by Leo Simons <ma...@leosimons.com>.
(On mobile)
Cool.
First I suggest to make a new branch from 1.2.17. Trunk has various stuff
that’s backwards incompatible. Something like
git checkout -b main v1_0_2_17
git push -u main
Then go into GitHub settings and make main the default branch.
So then people make PRs against that.
Think someone can take up to a5405370d844fca078c25f66654f929d07b1a922 from
https://github.com/apache/log4j/pull/17 to make a PR to get to a modern
build.
With some test failures because I got rid of the limited whitelist of unit
tests. Most of the commits after that set up GitHub actions and fix the
test suite.
I expect you can safely take everything on that PR17 that is a commit that
does not start with “fix:” without much discussion.
Each of those “fix:” commits from PR17 should then be a distinct PR and a
discussion, where based on Gary’s feedback most of them have a -1 against
them due to dropping functionality.
Instead of or in addition to some of those fixes, a nice alternative
approach that Vladimir suggested before is to split off the more
problematic integrations (jdbc,jms,smtp,telnet,plaintext socket) into their
own mini library jars. Then you can replace log4j-1.2.17.jar with
log4j-1.2.18.jar and in the rare(r) cases you do need the other stuff you
add in, say, log4j-jms-1.2.18.jar. Easy to understand, not too much effort.
The third approach, the one Gary suggested, is to backport (the idea of)
more secure code from 2.x.
Cheers,
Leo
On Thu, 23 Dec 2021 at 07:34, Ralph Goers <ra...@dslextreme.com>
wrote:
> I have cloned the read-only log4j repo to
> https://github.com/apache/logging-log4j1.
>
> I have followed the build instructions and had to modify the javadoc
> plugin to not fail on errors. Now it fails in the site plugin.
>
> If someone else wants to take this on I would suggest the first PR should
> just to the pom.xml file to get the build working as is.
>
> Ralph
>
>
>