You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Vladimir Sitnikov <si...@gmail.com> on 2021/12/14 14:09:19 UTC
Remove JMSAppender, JMSSink, SocketSerevr, SocketNode, ..., chainsaw, and ship it as 1.2.18
Hi,
I hope log4j finds you well :)
I know log4j 1.x has reached its end of life long ago,
however, I wonder if there's a possibility to ship 1.2.18 with
"network-related" classes removed.
The list of classes I suggest removing:
* JMSAppender: it looks like it might cause "remote code execution" issues
if an attacker can modify the logging configuration.
Frankly speaking, I would just remove the appender and what for what
happens.
* JMSSink, SocketServer, SocketNode, chainsaw: if somebody needs them, they
can use 1.2.17
A slightly better option would be moving the extra features to an extra
jar, however, it would require more effort, and I am not sure it is worth
doing.
My motivation is as follows:
* Everybody has questions on "what to do with log4j 1.x"
* There are applications that can't replace log4j 1 with 2 (e.g. they use
programmatic configuration)
* The maintenance overheads for releasing 1.2.18 do not seem to be severe.
At the end of the day, I suggest removing several classes and releasing it
* Dependabot would be able to bump log4j:log4j from 1.2.17 to 1.2.18
That is why I think releasing 1.2.18 as a "security hardened" version would
be good for everybody.
I think I can create a PR for the change, however, I can't really release
it without logging PMC.
WDYT?
See https://github.com/apache/logging-log4j2/pull/608#issuecomment-993430513
Vladimir
Re: Remove JMSAppender, JMSSink, SocketSerevr, SocketNode, ..., chainsaw, and ship it as 1.2.18
Posted by Ralph Goers <ra...@dslextreme.com>.
OK. We will look into this but you have to understand the priority of this is lower for us than getting all the Log4j 2 issues resolved. We are still swamped.
Ralph
> On Dec 14, 2021, at 8:03 AM, Vladimir Sitnikov <si...@gmail.com> wrote:
>
>> How would we then be able to ever release a log4j-1.2.19 jar if we find
>> another security vulnerability?
>
> I hope 1.2.19 won't be needed ;)
>
>> I believe that 1.2.17 targets Java 1.4(!)
>
> Java 1.8 can target 1.4 bytecode.
>
>> Also, I think we can consider not supporting any appenders that require
>> native code
>
> I'm not sure what to do with native code.
> It might be ok to drop the native appenders as well, as the overlap of
> those who use it and
> who can't upgrade and who needs a fix at the same time is probably close to
> zero.
>
> Vladimir
Re: Remove JMSAppender, JMSSink, SocketSerevr, SocketNode, ..., chainsaw, and ship it as 1.2.18
Posted by Vladimir Sitnikov <si...@gmail.com>.
>How would we then be able to ever release a log4j-1.2.19 jar if we find
>another security vulnerability?
I hope 1.2.19 won't be needed ;)
>I believe that 1.2.17 targets Java 1.4(!)
Java 1.8 can target 1.4 bytecode.
>Also, I think we can consider not supporting any appenders that require
>native code
I'm not sure what to do with native code.
It might be ok to drop the native appenders as well, as the overlap of
those who use it and
who can't upgrade and who needs a fix at the same time is probably close to
zero.
Vladimir
Re: Remove JMSAppender, JMSSink, SocketSerevr, SocketNode, ..., chainsaw, and ship it as 1.2.18
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Dec 14, 2021 at 9:54 AM Remko Popma <re...@gmail.com> wrote:
> On Tue, Dec 14, 2021 at 11:44 PM Vladimir Sitnikov <
> sitnikov.vladimir@gmail.com> wrote:
>
> > >My understanding is it requires an extremely
> > >old JDK.
> > >Have you actually tried building the project to see if this is true?
> >
> > I was able to build the project with Maven3 and Java 1.8 by commenting
> out
> > tools.jar, "site-related", "antrun-related" stuff in pom.xml.
> > It did produce logj4.jar that worked with Weblogic APP.
> >
> > ----
> >
> > There's an alternative option:
> > * cut the files from the source
> > * take log4j-1.2.17.jar
> > * remove the offending classes
> > * re-save the file as log4j-1.2.18.jar
> > * manually upload it to oss.sonatype.org via UI :)
>
I am sorry but this is not acceptable. Strictly speaking, Apache releases
source code, all binaries are just a convenience for our users, and, must
be built from source.
Gary
> >
> > It might be easier than trying to find the proper tools for the
> > compilation.
> >
>
> About the alternative solution:
> How would we then be able to ever release a log4j-1.2.19 jar if we find
> another security vulnerability? I don't like this idea.
>
> If we do a new Log4j 1.x release, we should do it from source.
> I believe that 1.2.17 targets Java 1.4(!), but it may be the case that the
> oldest JDK available from Oracle is Java 5.
> We can consider setting the compiler option to create Java 1.4 byte code,
> since we are only removing classes. (Vladimir, is this correct?)
>
> Also, I think we can consider not supporting any appenders that require
> native code.
> I believe that last one was one of the major stumbling blocks, I could be
> wrong.
>
>
> >
> > Vladimir
> >
>
Re: Remove JMSAppender, JMSSink, SocketSerevr, SocketNode, ..., chainsaw, and ship it as 1.2.18
Posted by Remko Popma <re...@gmail.com>.
On Tue, Dec 14, 2021 at 11:44 PM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> >My understanding is it requires an extremely
> >old JDK.
> >Have you actually tried building the project to see if this is true?
>
> I was able to build the project with Maven3 and Java 1.8 by commenting out
> tools.jar, "site-related", "antrun-related" stuff in pom.xml.
> It did produce logj4.jar that worked with Weblogic APP.
>
> ----
>
> There's an alternative option:
> * cut the files from the source
> * take log4j-1.2.17.jar
> * remove the offending classes
> * re-save the file as log4j-1.2.18.jar
> * manually upload it to oss.sonatype.org via UI :)
>
> It might be easier than trying to find the proper tools for the
> compilation.
>
About the alternative solution:
How would we then be able to ever release a log4j-1.2.19 jar if we find
another security vulnerability? I don't like this idea.
If we do a new Log4j 1.x release, we should do it from source.
I believe that 1.2.17 targets Java 1.4(!), but it may be the case that the
oldest JDK available from Oracle is Java 5.
We can consider setting the compiler option to create Java 1.4 byte code,
since we are only removing classes. (Vladimir, is this correct?)
Also, I think we can consider not supporting any appenders that require
native code.
I believe that last one was one of the major stumbling blocks, I could be
wrong.
>
> Vladimir
>
Re: Remove JMSAppender, JMSSink, SocketSerevr, SocketNode, ..., chainsaw, and ship it as 1.2.18
Posted by Ralph Goers <ra...@dslextreme.com>.
To be honest I hadn’t looked but just noticed https://logging.apache.org/log4j/1.2/building.html. I’m not sure
if I can get ahold of the windows dll but perhaps I can give it a try when I have time to breath.
Ralph
> On Dec 14, 2021, at 7:43 AM, Vladimir Sitnikov <si...@gmail.com> wrote:
>
>> My understanding is it requires an extremely
>> old JDK.
>> Have you actually tried building the project to see if this is true?
>
> I was able to build the project with Maven3 and Java 1.8 by commenting out
> tools.jar, "site-related", "antrun-related" stuff in pom.xml.
> It did produce logj4.jar that worked with Weblogic APP.
>
> ----
>
> There's an alternative option:
> * cut the files from the source
> * take log4j-1.2.17.jar
> * remove the offending classes
> * re-save the file as log4j-1.2.18.jar
> * manually upload it to oss.sonatype.org via UI :)
>
> It might be easier than trying to find the proper tools for the compilation.
>
> Vladimir
Re: Remove JMSAppender, JMSSink, SocketSerevr, SocketNode, ..., chainsaw, and ship it as 1.2.18
Posted by Vladimir Sitnikov <si...@gmail.com>.
>My understanding is it requires an extremely
>old JDK.
>Have you actually tried building the project to see if this is true?
I was able to build the project with Maven3 and Java 1.8 by commenting out
tools.jar, "site-related", "antrun-related" stuff in pom.xml.
It did produce logj4.jar that worked with Weblogic APP.
----
There's an alternative option:
* cut the files from the source
* take log4j-1.2.17.jar
* remove the offending classes
* re-save the file as log4j-1.2.18.jar
* manually upload it to oss.sonatype.org via UI :)
It might be easier than trying to find the proper tools for the compilation.
Vladimir
Re: Remove JMSAppender, JMSSink, SocketSerevr, SocketNode, ..., chainsaw, and ship it as 1.2.18
Posted by Remko Popma <re...@gmail.com>.
Hi Vladimir,
Thank you for your interest!
You mentioned that "The maintenance overheads for releasing 1.2.18 do not
seem to be severe".
Have you actually tried building the project to see if this is true?
Remko
On Tue, Dec 14, 2021 at 11:13 PM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> Hi,
>
> I hope log4j finds you well :)
> I know log4j 1.x has reached its end of life long ago,
> however, I wonder if there's a possibility to ship 1.2.18 with
> "network-related" classes removed.
>
> The list of classes I suggest removing:
> * JMSAppender: it looks like it might cause "remote code execution" issues
> if an attacker can modify the logging configuration.
> Frankly speaking, I would just remove the appender and what for what
> happens.
> * JMSSink, SocketServer, SocketNode, chainsaw: if somebody needs them, they
> can use 1.2.17
>
> A slightly better option would be moving the extra features to an extra
> jar, however, it would require more effort, and I am not sure it is worth
> doing.
>
> My motivation is as follows:
> * Everybody has questions on "what to do with log4j 1.x"
> * There are applications that can't replace log4j 1 with 2 (e.g. they use
> programmatic configuration)
> * The maintenance overheads for releasing 1.2.18 do not seem to be severe.
> At the end of the day, I suggest removing several classes and releasing it
> * Dependabot would be able to bump log4j:log4j from 1.2.17 to 1.2.18
>
> That is why I think releasing 1.2.18 as a "security hardened" version would
> be good for everybody.
>
> I think I can create a PR for the change, however, I can't really release
> it without logging PMC.
>
> WDYT?
>
> See
> https://github.com/apache/logging-log4j2/pull/608#issuecomment-993430513
>
> Vladimir
>
Re: Remove JMSAppender, JMSSink, SocketSerevr, SocketNode, ..., chainsaw, and ship it as 1.2.18
Posted by Ralph Goers <ra...@dslextreme.com>.
Virtually all of the contributors to the Log4j 1.x project left a few years before it was declared
EOL. That is the primary reason it was retired. Although the current set of committers have
access to the code, none of us have ever built it. My understanding is it requires an extremely
old JDK.
If you have people who know how to build it they would be welcome to do so. The PMC would
still have to vote on it and actually release it.
Ralph
> On Dec 14, 2021, at 7:09 AM, Vladimir Sitnikov <si...@gmail.com> wrote:
>
> Hi,
>
> I hope log4j finds you well :)
> I know log4j 1.x has reached its end of life long ago,
> however, I wonder if there's a possibility to ship 1.2.18 with
> "network-related" classes removed.
>
> The list of classes I suggest removing:
> * JMSAppender: it looks like it might cause "remote code execution" issues
> if an attacker can modify the logging configuration.
> Frankly speaking, I would just remove the appender and what for what
> happens.
> * JMSSink, SocketServer, SocketNode, chainsaw: if somebody needs them, they
> can use 1.2.17
>
> A slightly better option would be moving the extra features to an extra
> jar, however, it would require more effort, and I am not sure it is worth
> doing.
>
> My motivation is as follows:
> * Everybody has questions on "what to do with log4j 1.x"
> * There are applications that can't replace log4j 1 with 2 (e.g. they use
> programmatic configuration)
> * The maintenance overheads for releasing 1.2.18 do not seem to be severe.
> At the end of the day, I suggest removing several classes and releasing it
> * Dependabot would be able to bump log4j:log4j from 1.2.17 to 1.2.18
>
> That is why I think releasing 1.2.18 as a "security hardened" version would
> be good for everybody.
>
> I think I can create a PR for the change, however, I can't really release
> it without logging PMC.
>
> WDYT?
>
> See https://github.com/apache/logging-log4j2/pull/608#issuecomment-993430513
>
> Vladimir