Re: Looking for a champion: resurrect log4j 1.x

[Ralph Goers]

Justin, 

See https://lists.apache.org/thread/fz19gsjnlh84nxgxj0jyy2rzrol1dx9b 
 and 
https://twitter.com/qos_ch/status/1479938932213223424 
.

However, it is worth noting that https://github.com/albfernandez/log4j/ 
 has had a release in Maven Central for 
2 years and published 2 releases in the last month.

Ralph

> On Jan 9, 2022, at 12:35 AM, Justin Mclean  wrote:
> 
> Hi,
> 
> The incubation list for for conversations about new project proposals, 
> releases and graduations and similar things. I think this thread has got off 
> topic and you should probably carry on the conversation back on the logging 
> project lists.
> 
> Building a community around EOLed software, even if it is used would be 
> difficult. However, there is nothing stopping people who are interested 
> forking log4j 1.x and working on it elsewhere. Has that option been 
> considered?
> 
> Kind Regards,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
> 

Re: Looking for a champion: resurrect log4j 1.x

[Justin Mclean]

Hi,

The incubation list for for conversations about new project proposals, releases 
and graduations and similar things. I think this thread has got off topic and 
you should probably carry on the conversation back on the logging project lists.

Building a community around EOLed software, even if it is used would be 
difficult. However, there is nothing stopping people who are interested forking 
log4j 1.x and working on it elsewhere. Has that option been considered?

Kind Regards,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Looking for a champion: resurrect log4j 1.x

[Andrew Purtell]

The JMSAppender is an optional module. I think you will get the distinction. It 
doesn’t break the world to remove it, unlike changing the class hierarchy of 
Appender or removing a method on an extension interface used by same, I think 
the distinction is clear. We might find agreement in the response to concern 
about removal as “this is a maintenance version, you will need to upgrade”. The 
key is to take a practical approach to what the users are asking for now not a 
perhaps cleaner but absolutist position that strands and frustrates them. What 
we (users) are doing in the wild is simply taking the last log4j 1 release, 
removing JMSAppender.class from the JAR, and publishing them to our Nexus or 
whatever with a modified version. This is what regulators and compliance 
officers will care about. It is being done as a stopgap and I can’t say if it 
would be acceptable or not as a final solution. My guess is not, for what it’s 
worth. A release by the foundation would. Users do not need all theoretical CVE 
worthy issues addressed at at once, just the one. Just like many have avoided 
the concurrency issues listed earlier and don’t need up front solutions for 
those either. Just a new release without JMSAppender. 

> On Jan 8, 2022, at 6:34 PM, Matt Sicker  wrote:
> 
> 
>>> On Jan 8, 2022, at 19:39, Andrew Purtell  wrote:
>>> 
>>> Are you using the JMS appender? Are you using the socket receiver? If the
>> answer is no to those questions, you don’t have security concerns besides
>> the more glaring fact that you’re depending on end of life software that
>> has been marked as such for going on 7 years now.
>> 
>> I know you keep returning to the end of life designation in these
>> discussions, but do not acknowledge that the users of this EOL version were
>> deliberately stranded by incompatible API and configuration file formats.
>> There is a reason we are stuck on Log4J 1. I wish you could just hear this,
>> acknowledge it, and service the concerns of users in this regard without
>> the dictatorial attitude by continuing to release version 1 with security
>> fixes applied. That's all I think interested parties here want.
> 
> Which security fixes? Part of the EOL status has meant that anytime someone 
> has tried reporting a new security vulnerability in log4j1, we’ve informed 
> them that the version is EOL. No new CVEs published. Being EOL, less security 
> review is being done other than thorough audits of old software. This would 
> be like opening Pandora’s Box, and that’s one of the reasons why software is 
> sometimes effectively abandoned before being declared end of life.
> 
>> My employer, for example, will be forced to accommodate government
>> compliance officers' demands for a CVE-free version of Log4J to be included
>> in our products. If Log4J 1 were to satisfy that requirement, this
>> necessitates at least a release of 1 without the JMSAppender or with the
>> JNDI issues therein addressed some other way. (I would advocate removal.)
> 
> So you couldn’t upgrade to version 2 due to incompatibility (which still has 
> no concrete examples; did you know that we’ve improved compatibility several 
> times since version 2.0?), yet right out of the gate you want to break 
> compatibility in version 1 by just nuking a feature.
> 
>> Since I volunteered on this thread to maintain a resurrected Log4J 1 --
>> whatever form that would take can be debated, it's not material for this
>> point -- this would be the maintenance philosophy I would adopt or
>> advocate, for what it is worth:
>> 
>>  - Start with latest/last Log4J 1 release.
>>  - Security vulnerabilities addressed. JMSAppender to be immediately
>>  removed.
> 
> To be more constructive, I’d suggest following the compatibility-oriented 
> philosophy of guarding this class with a feature flag to opt in. Being such 
> an old library used so extensively, there are bound to be a non-trivial 
> number of legitimate users of this appender.
> 
>>  - Pay down the build system tech debt - migrate to Maven 3.
> 
> That would be expected; I wouldn’t want anyone to have to dig up ancient VMs 
> just to build and release the project!
> 
>>  - No API changes.
> 
> This makes sense of course, but I should note that one of the historical 
> reasons why both Logback and Log4j2 exist is because Log4j1 doesn’t have a 
> clear delineation between its API and implementation, and some problems 
> cannot be fixed without breaking the effective API.
> 
>>  - No new appenders.
>>  - Additional security fixes as required. Typical 'maintenance mode'
>>  stuff.
> 
> Given the limited changes desired (which mostly sound fine otherwise), I 
> don’t have a real problem with doing this. Not everyone on the PMC has the 
> same opinions, but we all agreed on making it EOL. One of the recurring 
> concerns, though, was that continued maintenance of version 1 in any form 
> will require adding someone to the PMC to oversee that as no one else in the 
> current PMC wants 

Re: Looking for a champion: resurrect log4j 1.x

[Matt Sicker]

> On Jan 8, 2022, at 19:39, Andrew Purtell  wrote:
> 
>> Are you using the JMS appender? Are you using the socket receiver? If the
> answer is no to those questions, you don’t have security concerns besides
> the more glaring fact that you’re depending on end of life software that
> has been marked as such for going on 7 years now.
> 
> I know you keep returning to the end of life designation in these
> discussions, but do not acknowledge that the users of this EOL version were
> deliberately stranded by incompatible API and configuration file formats.
> There is a reason we are stuck on Log4J 1. I wish you could just hear this,
> acknowledge it, and service the concerns of users in this regard without
> the dictatorial attitude by continuing to release version 1 with security
> fixes applied. That's all I think interested parties here want.

Which security fixes? Part of the EOL status has meant that anytime someone has 
tried reporting a new security vulnerability in log4j1, we’ve informed them 
that the version is EOL. No new CVEs published. Being EOL, less security review 
is being done other than thorough audits of old software. This would be like 
opening Pandora’s Box, and that’s one of the reasons why software is sometimes 
effectively abandoned before being declared end of life.

> My employer, for example, will be forced to accommodate government
> compliance officers' demands for a CVE-free version of Log4J to be included
> in our products. If Log4J 1 were to satisfy that requirement, this
> necessitates at least a release of 1 without the JMSAppender or with the
> JNDI issues therein addressed some other way. (I would advocate removal.)

So you couldn’t upgrade to version 2 due to incompatibility (which still has no 
concrete examples; did you know that we’ve improved compatibility several times 
since version 2.0?), yet right out of the gate you want to break compatibility 
in version 1 by just nuking a feature.

> Since I volunteered on this thread to maintain a resurrected Log4J 1 --
> whatever form that would take can be debated, it's not material for this
> point -- this would be the maintenance philosophy I would adopt or
> advocate, for what it is worth:
> 
>   - Start with latest/last Log4J 1 release.
>   - Security vulnerabilities addressed. JMSAppender to be immediately
>   removed.

To be more constructive, I’d suggest following the compatibility-oriented 
philosophy of guarding this class with a feature flag to opt in. Being such an 
old library used so extensively, there are bound to be a non-trivial number of 
legitimate users of this appender.

>   - Pay down the build system tech debt - migrate to Maven 3.

That would be expected; I wouldn’t want anyone to have to dig up ancient VMs 
just to build and release the project!

>   - No API changes.

This makes sense of course, but I should note that one of the historical 
reasons why both Logback and Log4j2 exist is because Log4j1 doesn’t have a 
clear delineation between its API and implementation, and some problems cannot 
be fixed without breaking the effective API.

>   - No new appenders.
>   - Additional security fixes as required. Typical 'maintenance mode'
>   stuff.

Given the limited changes desired (which mostly sound fine otherwise), I don’t 
have a real problem with doing this. Not everyone on the PMC has the same 
opinions, but we all agreed on making it EOL. One of the recurring concerns, 
though, was that continued maintenance of version 1 in any form will require 
adding someone to the PMC to oversee that as no one else in the current PMC 
wants to do the release work. Joining the PMC isn’t a trivial thing; it 
requires some sustained commitment to the project by first becoming a committer 
and then being invited to the PMC. This is also why I’ve suggested it could 
help to contribute to the backward compatibility of version 2 as a related way 
to do something that could easily lead to becoming a committer.

> I have lurked in some discussion here and elsewhere and I really don't see
> that much daylight between the Logging PMCs position on 1 and what users
> like myself want of it. I hear concerns about resurrecting 1 that seem
> focused on some theoretical future development of 1 that I don't think
> anyone is actually interested in doing. If I can be said to be
> representative of a Log4J 1 user that would like to stay on 1, the vision
> is "just fix security bugs, please, we will upgrade or migrate to something
> else someday, don't change API or configuration file formats, thanks".
> There exists the possibility that some day a theoretical required security
> fix cannot be accomplished without a breaking change. We can cross that
> bridge when and if we come to it. It may never happen. Or, it might, and
> then 1 has truly reached the end of the road.

Deleting those appenders is a breaking change. And I suspect fixing some things 
might be breaking changes based on the history of the PMC here: 

Re: Looking for a champion: resurrect log4j 1.x

[Dave Fisher]

In this current form this discussion belongs either on dev@logging or board@.

Several people here are perfectly capable of forming a proposal, but are 
choosing to have an unproductive discussion.

At this point a new podling would be a hostile fork and those are not accepted.

Sent from my iPhone

> On Jan 8, 2022, at 5:44 PM, Andrew Purtell  wrote:
> 
> The discussion continues here because the Logging PMC is intransigent and
> non-responsive to the concerns already well established by parties on this
> thread. I don't see how this can be resolved without you "giving in".
> Perhaps that is the problem, but I don't want to be an armchair
> psychiatrist, I just want a logging library without known security bugs
> that remains compatible with existing code and configuration formats and
> does not force me to transitively upgrade/rebuild/modify the world.
> 
>> On Sat, Jan 8, 2022 at 5:00 PM Ralph Goers 
>> wrote:
>> 
>> 
>> 
 On Jan 8, 2022, at 4:34 PM, Andrew Purtell  wrote:
>>> 
>>> The Logging PMC is the hostile party here as far as I can tell, operating
>>> in defiance of the community of users that have made the points I have
>> just
>>> written here abundantly clear for years.
>> 
>> The Logging PMC is the owner of Log4j 1.x. We declared it EOL in 2015. Not
>> one single complaint was received nor were any proposals made to the PMC
>> until over 6 years later. This is not the sign of a hostile PMC but one
>> that has
>> moved on from unmaintainable software. Heck, even Ceki abandoned it years
>> before its last release to concentrate on its replacement.
>> 
>> The PMC held a discussion on the dev mailing list. Out of non-PMC members
>> there were very few responses. One person was in favor of reviving the
>> project
>> even to the point of fixing bugs and continuing development beyond just
>> fixing
>> CVEs. Leo Simmons did offer to help. Here is what he said during the
>> discussion:
>> 
>>I think I made clear what I am interested in through several emails
>> and in code.
>>I've also pointed out what I wouldn't do (like step up as a maintainer
>> on a.
>>permanent basis, or incubate something).
>> 
>>I think all the relevant arguments on how to proceed with 1.x have been
>>made (a few times…).
>>I don't have anything new to add.
>>I'll accept the vote outcome.
>> 
>> So we had two people expressing interest, one with no hope of ever being
>> offered
>> commit rights due to his behavior on our lists and in reviewing the other
>> projects
>> he participates on.
>> 
>> So we were left with the choice of us allowing Leo to do that work and us
>> having
>> to spend time reviewing the PRs and applying them. Frankly, none of us
>> were
>> interested enough in this to spend that kind of time, especially since we
>> know at
>> least two usable drop-in replacements for Log4j 1.2 that fix the CVEs
>> already exist.
>> 
>> I seriously think the outcome would have been different had Ceki offered
>> to help
>> while the discussion was going on. Instead, he decided to offer to help
>> after the
>> PMC posted its announcement of the vote results and the reasons why we
>> voted
>> that way.
>> 
>> Since the Logging Services PMC is responsible for Log4j1 I fail to see why
>> a
>> discussion is even continuing on this list. The Logging Services PMC has
>> made
>> clear that it is not going to sponsor a podling for this and the PMC still
>> retains
>> ownership of the code.
>> 
>> Ralph
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
>> 
> 
> -- 
> Best regards,
> Andrew
> 
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>   - A23, Crosstalk


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Looking for a champion: resurrect log4j 1.x

[Andrew Purtell]

The discussion continues here because the Logging PMC is intransigent and
non-responsive to the concerns already well established by parties on this
thread. I don't see how this can be resolved without you "giving in".
Perhaps that is the problem, but I don't want to be an armchair
psychiatrist, I just want a logging library without known security bugs
that remains compatible with existing code and configuration formats and
does not force me to transitively upgrade/rebuild/modify the world.

On Sat, Jan 8, 2022 at 5:00 PM Ralph Goers 
wrote:

>
>
> > On Jan 8, 2022, at 4:34 PM, Andrew Purtell  wrote:
> >
> > The Logging PMC is the hostile party here as far as I can tell, operating
> > in defiance of the community of users that have made the points I have
> just
> > written here abundantly clear for years.
>
> The Logging PMC is the owner of Log4j 1.x. We declared it EOL in 2015. Not
> one single complaint was received nor were any proposals made to the PMC
> until over 6 years later. This is not the sign of a hostile PMC but one
> that has
> moved on from unmaintainable software. Heck, even Ceki abandoned it years
> before its last release to concentrate on its replacement.
>
> The PMC held a discussion on the dev mailing list. Out of non-PMC members
> there were very few responses. One person was in favor of reviving the
> project
> even to the point of fixing bugs and continuing development beyond just
> fixing
> CVEs. Leo Simmons did offer to help. Here is what he said during the
> discussion:
>
> I think I made clear what I am interested in through several emails
> and in code.
> I've also pointed out what I wouldn't do (like step up as a maintainer
> on a.
> permanent basis, or incubate something).
>
> I think all the relevant arguments on how to proceed with 1.x have been
> made (a few times…).
> I don't have anything new to add.
> I'll accept the vote outcome.
>
> So we had two people expressing interest, one with no hope of ever being
> offered
> commit rights due to his behavior on our lists and in reviewing the other
> projects
> he participates on.
>
> So we were left with the choice of us allowing Leo to do that work and us
> having
> to spend time reviewing the PRs and applying them. Frankly, none of us
> were
> interested enough in this to spend that kind of time, especially since we
> know at
> least two usable drop-in replacements for Log4j 1.2 that fix the CVEs
> already exist.
>
> I seriously think the outcome would have been different had Ceki offered
> to help
> while the discussion was going on. Instead, he decided to offer to help
> after the
> PMC posted its announcement of the vote results and the reasons why we
> voted
> that way.
>
> Since the Logging Services PMC is responsible for Log4j1 I fail to see why
> a
> discussion is even continuing on this list. The Logging Services PMC has
> made
> clear that it is not going to sponsor a podling for this and the PMC still
> retains
> ownership of the code.
>
> Ralph
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: Looking for a champion: resurrect log4j 1.x

[Andrew Purtell]

> Are you using the JMS appender? Are you using the socket receiver? If the
answer is no to those questions, you don’t have security concerns besides
the more glaring fact that you’re depending on end of life software that
has been marked as such for going on 7 years now.

I know you keep returning to the end of life designation in these
discussions, but do not acknowledge that the users of this EOL version were
deliberately stranded by incompatible API and configuration file formats.
There is a reason we are stuck on Log4J 1. I wish you could just hear this,
acknowledge it, and service the concerns of users in this regard without
the dictatorial attitude by continuing to release version 1 with security
fixes applied. That's all I think interested parties here want.

My employer, for example, will be forced to accommodate government
compliance officers' demands for a CVE-free version of Log4J to be included
in our products. If Log4J 1 were to satisfy that requirement, this
necessitates at least a release of 1 without the JMSAppender or with the
JNDI issues therein addressed some other way. (I would advocate removal.)

Since I volunteered on this thread to maintain a resurrected Log4J 1 --
whatever form that would take can be debated, it's not material for this
point -- this would be the maintenance philosophy I would adopt or
advocate, for what it is worth:

   - Start with latest/last Log4J 1 release.
   - Security vulnerabilities addressed. JMSAppender to be immediately
   removed.
   - Pay down the build system tech debt - migrate to Maven 3.
   - No API changes.
   - No new appenders.
   - Additional security fixes as required. Typical 'maintenance mode'
   stuff.

I have lurked in some discussion here and elsewhere and I really don't see
that much daylight between the Logging PMCs position on 1 and what users
like myself want of it. I hear concerns about resurrecting 1 that seem
focused on some theoretical future development of 1 that I don't think
anyone is actually interested in doing. If I can be said to be
representative of a Log4J 1 user that would like to stay on 1, the vision
is "just fix security bugs, please, we will upgrade or migrate to something
else someday, don't change API or configuration file formats, thanks".
There exists the possibility that some day a theoretical required security
fix cannot be accomplished without a breaking change. We can cross that
bridge when and if we come to it. It may never happen. Or, it might, and
then 1 has truly reached the end of the road.

On Sat, Jan 8, 2022 at 4:17 PM Matt Sicker  wrote:

> Answers below:
>
> > On Jan 8, 2022, at 17:34, Andrew Purtell  wrote:
> >
> > Log4J 1 has known concurrency issues but many projects live with them or
> > work around them. For example, several "Big Data" Apache projects have
> been
> > fine with it, themselves internally highly concurrent and performance
> > sensitive. Log4J 1 might not be a Platonic ideal, but certainly good
> > enough, as evidenced by the popularity of those projects, operational in
> > numerous high scale and/or performance sensitive environments.
>
> It’s also a fairly common source of application performance problems that
> leads to reduction in logs being stored and the added difficulty of
> debugging problems with less context. Here are just some of the Bugzilla
> issues you’ve been conveniently ignoring for years:
>
> 50213   Category callAppenders synchronization causes
> java.lang.Thread.State: BLOCKED
> 46878   Deadlock in 1.2.15 caused by AsyncAppender and
> ThrowableInformation classes
> 41214   Deadlock with RollingFileAppender
> 44700   Log4J locks rolled log files (files can’t be deleted)
> 49481   Log4j stops writing to file, and then causes server to lockup
> 50323   Vulnerability in NTEventLogAppender
> 50463   AsyncAppender causing deadlock when dispatcher thread dies
> 50858   Classloader leak when using Log4j in a webapp container such as
> Tomcat, WebLogic
> 52141   [STUCK] ExecuteThread...Blocked trying to get lock:
> org/apache/log4j/Logger@0xc501e0a8[fat lock]
> 54009   Thread is getting Blocked
> 54325   Concurrency issues in AppenderAttachableImpl
>
> > In a perfect world Log4J 2 would have been API compatible and
> configuration
> > format compatible with 1, such that everyone could have migrated years
> ago,
>
> Can you point out any specific incompatibilities? Particularly in the
> current version.
>
> > but the Logging PMC/devs decided otherwise. Whether or not we assess that
> > as desirable, we arrive at the present, with hundreds, perhaps thousands,
> > of open source and internal projects stuck on Log4J 1 due to API or
> > operational compatibility concerns that would carry downstream to their
> > users. No matter what direction one might look (Log4J2, logback, etc.)
> > there are compatibility blockers. Staying with Log4J 1 can be very much
> > acceptable for this reason if the security concerns are addressed.
>
> Are you using the JMS appender? Are you using 

Re: Looking for a champion: resurrect log4j 1.x

[Ralph Goers]

> On Jan 8, 2022, at 4:34 PM, Andrew Purtell  wrote:
> 
> The Logging PMC is the hostile party here as far as I can tell, operating
> in defiance of the community of users that have made the points I have just
> written here abundantly clear for years.

The Logging PMC is the owner of Log4j 1.x. We declared it EOL in 2015. Not 
one single complaint was received nor were any proposals made to the PMC 
until over 6 years later. This is not the sign of a hostile PMC but one that 
has 
moved on from unmaintainable software. Heck, even Ceki abandoned it years 
before its last release to concentrate on its replacement.

The PMC held a discussion on the dev mailing list. Out of non-PMC members 
there were very few responses. One person was in favor of reviving the project 
even to the point of fixing bugs and continuing development beyond just fixing 
CVEs. Leo Simmons did offer to help. Here is what he said during the discussion:

I think I made clear what I am interested in through several emails and in 
code.
I've also pointed out what I wouldn't do (like step up as a maintainer on 
a.  
permanent basis, or incubate something).

I think all the relevant arguments on how to proceed with 1.x have been
made (a few times…).
I don't have anything new to add.
I'll accept the vote outcome.

So we had two people expressing interest, one with no hope of ever being 
offered 
commit rights due to his behavior on our lists and in reviewing the other 
projects 
he participates on.

So we were left with the choice of us allowing Leo to do that work and us 
having 
to spend time reviewing the PRs and applying them. Frankly, none of us were 
interested enough in this to spend that kind of time, especially since we know 
at 
least two usable drop-in replacements for Log4j 1.2 that fix the CVEs already 
exist.

I seriously think the outcome would have been different had Ceki offered to 
help 
while the discussion was going on. Instead, he decided to offer to help after 
the 
PMC posted its announcement of the vote results and the reasons why we voted 
that way.

Since the Logging Services PMC is responsible for Log4j1 I fail to see why a 
discussion is even continuing on this list. The Logging Services PMC has made 
clear that it is not going to sponsor a podling for this and the PMC still 
retains 
ownership of the code.

Ralph
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Looking for a champion: resurrect log4j 1.x

[Matt Sicker]

Answers below:

> On Jan 8, 2022, at 17:34, Andrew Purtell  wrote:
> 
> Log4J 1 has known concurrency issues but many projects live with them or
> work around them. For example, several "Big Data" Apache projects have been
> fine with it, themselves internally highly concurrent and performance
> sensitive. Log4J 1 might not be a Platonic ideal, but certainly good
> enough, as evidenced by the popularity of those projects, operational in
> numerous high scale and/or performance sensitive environments.

It’s also a fairly common source of application performance problems that leads 
to reduction in logs being stored and the added difficulty of debugging 
problems with less context. Here are just some of the Bugzilla issues you’ve 
been conveniently ignoring for years:

50213   Category callAppenders synchronization causes java.lang.Thread.State: 
BLOCKED
46878   Deadlock in 1.2.15 caused by AsyncAppender and ThrowableInformation 
classes
41214   Deadlock with RollingFileAppender
44700   Log4J locks rolled log files (files can’t be deleted)
49481   Log4j stops writing to file, and then causes server to lockup
50323   Vulnerability in NTEventLogAppender
50463   AsyncAppender causing deadlock when dispatcher thread dies
50858   Classloader leak when using Log4j in a webapp container such as Tomcat, 
WebLogic
52141   [STUCK] ExecuteThread...Blocked trying to get lock: 
org/apache/log4j/Logger@0xc501e0a8[fat lock]
54009   Thread is getting Blocked
54325   Concurrency issues in AppenderAttachableImpl

> In a perfect world Log4J 2 would have been API compatible and configuration
> format compatible with 1, such that everyone could have migrated years ago,

Can you point out any specific incompatibilities? Particularly in the current 
version.

> but the Logging PMC/devs decided otherwise. Whether or not we assess that
> as desirable, we arrive at the present, with hundreds, perhaps thousands,
> of open source and internal projects stuck on Log4J 1 due to API or
> operational compatibility concerns that would carry downstream to their
> users. No matter what direction one might look (Log4J2, logback, etc.)
> there are compatibility blockers. Staying with Log4J 1 can be very much
> acceptable for this reason if the security concerns are addressed.

Are you using the JMS appender? Are you using the socket receiver? If the 
answer is no to those questions, you don’t have security concerns besides the 
more glaring fact that you’re depending on end of life software that has been 
marked as such for going on 7 years now.

> Sure, it
> won't evolve much, and there will remain gotchas, but that is true with
> anything... Some gotchas exceed others in concern. Compare lack of
> asynchronous logging with the risks of a turing complete substitution
> engine operating on untrusted user input.

This is bullshit. JNDI is what leads to your Turing completeness. Not to 
mention that this substitution feature is meant for the configuration file, not 
for log messages, and the library has been updated as such regardless of 
downstream users possibly relying on the default behavior before it was 
apparent there was a security flaw. Based on how tepid you are about upgrading 
for even the slightest inconvenience, there’s a reason why version 2 maintains 
as much backward compatibility as possible by default to be least surprising. 
Plenty of work and security review has since been put into the library to 
disable and remove everything concerning related to string substitution of 
configuration files using JNDI, but this is also a wider problem for any 
library or application that uses JNDI without restricting it to only java URIs 
(e.g., users that use LDAP via JNDI).

If the only reason you want to resurrect version 1 is due to a bug in version 
2, then I suggest you leave the software industry entirely as nearly 100% of 
software in existence has flaws, many of them critical.

> The Logging PMC is the hostile party here as far as I can tell, operating
> in defiance of the community of users that have made the points I have just
> written here abundantly clear for years.

So far, we had one contributor show up with a complete hostile attitude who 
refused to engage with the PMC and explain what he wanted to do besides go wild 
with version 1. Later, Ceki came back and made his first commit in probably a 
decade attempting to do the same less than a day after we had completed voting 
on what to do with version 1, again, without ANY comments about what his 
intentions were or any engagement with the PMC. So far, these two people have 
spent most of their time trolling in other mailing lists on Apache or elsewhere 
about the situation while continuing to ignore the PMC’s arguments.

If you have a desire to update version 1 that doesn’t boil down to “log4j2 bad 
bcuz log4shell lol get rekt n00bz”, please explain.

> 
> On Sat, Jan 8, 2022 at 1:58 PM Matt Sicker  wrote:
> 
>> The problem with v1 is that it doesn’t “just work”. There are 

Re: Looking for a champion: resurrect log4j 1.x

[Andrew Purtell]

Log4J 1 has known concurrency issues but many projects live with them or
work around them. For example, several "Big Data" Apache projects have been
fine with it, themselves internally highly concurrent and performance
sensitive. Log4J 1 might not be a Platonic ideal, but certainly good
enough, as evidenced by the popularity of those projects, operational in
numerous high scale and/or performance sensitive environments.

In a perfect world Log4J 2 would have been API compatible and configuration
format compatible with 1, such that everyone could have migrated years ago,
but the Logging PMC/devs decided otherwise. Whether or not we assess that
as desirable, we arrive at the present, with hundreds, perhaps thousands,
of open source and internal projects stuck on Log4J 1 due to API or
operational compatibility concerns that would carry downstream to their
users. No matter what direction one might look (Log4J2, logback, etc.)
there are compatibility blockers. Staying with Log4J 1 can be very much
acceptable for this reason if the security concerns are addressed. Sure, it
won't evolve much, and there will remain gotchas, but that is true with
anything... Some gotchas exceed others in concern. Compare lack of
asynchronous logging with the risks of a turing complete substitution
engine operating on untrusted user input.

The Logging PMC is the hostile party here as far as I can tell, operating
in defiance of the community of users that have made the points I have just
written here abundantly clear for years.

On Sat, Jan 8, 2022 at 1:58 PM Matt Sicker  wrote:

> The problem with v1 is that it doesn’t “just work”. There are numerous
> dead locks and other concurrency problems that were unable to be fixed
> without breaking various points of compatibility which is why Logback and
> Log4j2 even exist rather than continuing v1. There would also be difficulty
> in making a new release without volunteers contributing to the existing PMC
> to eventually join the PMC to be able to more directly create releases.
> Apache isn’t going to allow a hostile fork at the Incubator, so it’d still
> need to work with us or create an external fork that can’t be confused with
> the Apache version (which would still require a bunch of source code
> changes to point to the new package name if not already using shading or
> similar repackaging).
>
> I think it’s been said before, but contributing to the v2 backward
> compatibility system is a great way to join the project in such a way as to
> eventually form new releases of v1 with a greater understanding of the full
> impact of changing anything about v1 after such a long time. A poorly made
> release still wouldn’t be a drop in upgrade for projects that haven’t
> bothered upgrading in several years, and one that starts to introduce
> incompatible API changes would further complicate backward compatibility in
> v2 as well as complicating external projects that rely on a stable legacy
> API to convert from (like Logback’s config file converter thing or the
> numerous custom plugins for v1). So far, we haven’t seen any reasonably
> serious proposals of how anyone expects to do this without causing further
> mayhem in the future.
>
> —
> Matt Sicker
>
> > On Jan 8, 2022, at 14:32, Rohit Yadav  wrote:
> >
> > Hi Matt,
> >
> > Thanks for replying. I think the main issues I found following the guide
> [1] for Apache CloudStack (ACS) are:
> >
> > - APIs are not backward compatible fully, certainly everywhere the
> imports have to be fixed
> > - The config xml files are not fully compatible requiring some changes
> > - Our codebase is pretty large with several maven modules/projects
> enabled by certain flags, testing changes and ensuring CloudStack works
> post-migration adds effort and risks
> > - Lack of an automatic tooling that can do this reliably and efficiently
> (for example, the Go lang ecosystem has gofmt and other tooling to migrate
> codebase across std library/lang changes).
> > - ACS's own tech debt and dependency issues: for example, we're using
> log4j-extras (https://logging.apache.org/log4j/extras/) which is
> completely discontinued, and have code tied around gson library (for one or
> more reason, we've hesitated to upgrade both log4j and gson dependencies)
> >
> > Appreciate all the hard work the Log4j team is doing and we'll report
> issues as/when we hit them. As a consumer of the dependency, 1.x gave us
> enough mileage and end of the day we want logging to be boring that just
> works; and therefore I'm simply exploring all possible options (both
> migration to 2.x or support/maintain 1.x fork) while understanding their
> tradeoffs.
> >
> > [1] https://logging.apache.org/log4j/2.x/manual/migration.html
> >
> >> On 2022/01/08 19:51:07 Matt Sicker wrote:
> >> It would be nice if you filed any issues with Log4j2 about problems
> with migration. It would have been nice to hear about these issues back
> when v1 stopped development, but this is the next best time to do 

Re: Looking for a champion: resurrect log4j 1.x

[Matt Sicker]

The problem with v1 is that it doesn’t “just work”. There are numerous dead 
locks and other concurrency problems that were unable to be fixed without 
breaking various points of compatibility which is why Logback and Log4j2 even 
exist rather than continuing v1. There would also be difficulty in making a new 
release without volunteers contributing to the existing PMC to eventually join 
the PMC to be able to more directly create releases. Apache isn’t going to 
allow a hostile fork at the Incubator, so it’d still need to work with us or 
create an external fork that can’t be confused with the Apache version (which 
would still require a bunch of source code changes to point to the new package 
name if not already using shading or similar repackaging).

I think it’s been said before, but contributing to the v2 backward 
compatibility system is a great way to join the project in such a way as to 
eventually form new releases of v1 with a greater understanding of the full 
impact of changing anything about v1 after such a long time. A poorly made 
release still wouldn’t be a drop in upgrade for projects that haven’t bothered 
upgrading in several years, and one that starts to introduce incompatible API 
changes would further complicate backward compatibility in v2 as well as 
complicating external projects that rely on a stable legacy API to convert from 
(like Logback’s config file converter thing or the numerous custom plugins for 
v1). So far, we haven’t seen any reasonably serious proposals of how anyone 
expects to do this without causing further mayhem in the future.

—
Matt Sicker

> On Jan 8, 2022, at 14:32, Rohit Yadav  wrote:
> 
> Hi Matt,
> 
> Thanks for replying. I think the main issues I found following the guide [1] 
> for Apache CloudStack (ACS) are:
> 
> - APIs are not backward compatible fully, certainly everywhere the imports 
> have to be fixed
> - The config xml files are not fully compatible requiring some changes
> - Our codebase is pretty large with several maven modules/projects enabled by 
> certain flags, testing changes and ensuring CloudStack works post-migration 
> adds effort and risks
> - Lack of an automatic tooling that can do this reliably and efficiently (for 
> example, the Go lang ecosystem has gofmt and other tooling to migrate 
> codebase across std library/lang changes).
> - ACS's own tech debt and dependency issues: for example, we're using 
> log4j-extras (https://logging.apache.org/log4j/extras/) which is completely 
> discontinued, and have code tied around gson library (for one or more reason, 
> we've hesitated to upgrade both log4j and gson dependencies)
> 
> Appreciate all the hard work the Log4j team is doing and we'll report issues 
> as/when we hit them. As a consumer of the dependency, 1.x gave us enough 
> mileage and end of the day we want logging to be boring that just works; and 
> therefore I'm simply exploring all possible options (both migration to 2.x or 
> support/maintain 1.x fork) while understanding their tradeoffs.
> 
> [1] https://logging.apache.org/log4j/2.x/manual/migration.html
> 
>> On 2022/01/08 19:51:07 Matt Sicker wrote:
>> It would be nice if you filed any issues with Log4j2 about problems with 
>> migration. It would have been nice to hear about these issues back when v1 
>> stopped development, but this is the next best time to do so. The Log4j team 
>> are actively working to fill in any remaining gaps on backward 
>> compatibility; making new releases of EOL software with numerous 
>> implementation errors inherent to its architecture seems like going 
>> backwards.
>> 
>> —
>> Matt Sicker
>> 
 On Jan 8, 2022, at 13:45, Rohit Yadav  wrote:
>>> 
>>> Hi all, 
>>> 
>>> I agree and extend support for Andrew's remarks. Apache CloudStack too uses 
>>> log4j 1.x and our use case is simply a logging library that 1.x just 
>>> satisfies. The effort to migrate to 2.x is not quick, at least in our 
>>> initial investigation and a migration may likely require huge effort in 
>>> testing.
>>> 
>>> Assuming this quick upgrade path doesn't exist, and I already read 
>>> struggles by other projects trying to migrate to 2.x - maintaining 1.x and 
>>> doing a 1.2.x release makes more sense than investing weeks in migration 
>>> and testing to 2.x, while maintaining the same artifact IDs. I'm up for 
>>> volunteering and supporting 1.x maintenance.
>>> 
>>> Regards, 
>>> Rohit Yadav 
>>> PMC, Apache CloudStack
>>> 
>>> On 2021/12/21 21:54:34 Andrew Purtell wrote:
> as for the v1 :: COBOL analogy, that’s not a bad comparison. Basically,
 users who haven’t bothered to upgrade in 10 years will have to end up
 paying astronomical costs for consultants who can still work on ancient
 software effectively to help modify their systems.
 
 I have to take some exception to this. If the log4j 2.x configuration files
 were compatible _enough_ with 1.x then taking this position would be
 understandable. However, because 

Re: Looking for a champion: resurrect log4j 1.x

[Rohit Yadav]

Hi Matt,

Thanks for replying. I think the main issues I found following the guide [1] 
for Apache CloudStack (ACS) are:

- APIs are not backward compatible fully, certainly everywhere the imports have 
to be fixed
- The config xml files are not fully compatible requiring some changes
- Our codebase is pretty large with several maven modules/projects enabled by 
certain flags, testing changes and ensuring CloudStack works post-migration 
adds effort and risks
- Lack of an automatic tooling that can do this reliably and efficiently (for 
example, the Go lang ecosystem has gofmt and other tooling to migrate codebase 
across std library/lang changes).
- ACS's own tech debt and dependency issues: for example, we're using 
log4j-extras (https://logging.apache.org/log4j/extras/) which is completely 
discontinued, and have code tied around gson library (for one or more reason, 
we've hesitated to upgrade both log4j and gson dependencies)

Appreciate all the hard work the Log4j team is doing and we'll report issues 
as/when we hit them. As a consumer of the dependency, 1.x gave us enough 
mileage and end of the day we want logging to be boring that just works; and 
therefore I'm simply exploring all possible options (both migration to 2.x or 
support/maintain 1.x fork) while understanding their tradeoffs.

[1] https://logging.apache.org/log4j/2.x/manual/migration.html

On 2022/01/08 19:51:07 Matt Sicker wrote:
> It would be nice if you filed any issues with Log4j2 about problems with 
> migration. It would have been nice to hear about these issues back when v1 
> stopped development, but this is the next best time to do so. The Log4j team 
> are actively working to fill in any remaining gaps on backward compatibility; 
> making new releases of EOL software with numerous implementation errors 
> inherent to its architecture seems like going backwards.
> 
> —
> Matt Sicker
> 
> > On Jan 8, 2022, at 13:45, Rohit Yadav  wrote:
> > 
> > Hi all, 
> > 
> > I agree and extend support for Andrew's remarks. Apache CloudStack too uses 
> > log4j 1.x and our use case is simply a logging library that 1.x just 
> > satisfies. The effort to migrate to 2.x is not quick, at least in our 
> > initial investigation and a migration may likely require huge effort in 
> > testing.
> > 
> > Assuming this quick upgrade path doesn't exist, and I already read 
> > struggles by other projects trying to migrate to 2.x - maintaining 1.x and 
> > doing a 1.2.x release makes more sense than investing weeks in migration 
> > and testing to 2.x, while maintaining the same artifact IDs. I'm up for 
> > volunteering and supporting 1.x maintenance.
> > 
> > Regards, 
> > Rohit Yadav 
> > PMC, Apache CloudStack
> > 
> > On 2021/12/21 21:54:34 Andrew Purtell wrote:
> >>> as for the v1 :: COBOL analogy, that’s not a bad comparison. Basically,
> >> users who haven’t bothered to upgrade in 10 years will have to end up
> >> paying astronomical costs for consultants who can still work on ancient
> >> software effectively to help modify their systems.
> >> 
> >> I have to take some exception to this. If the log4j 2.x configuration files
> >> were compatible _enough_ with 1.x then taking this position would be
> >> understandable. However, because they are not compatible in the way that
> >> users require -- and the backwards compatibility is still marked as
> >> 'experimental', even -- it is not great to blame users "who haven't
> >> bothered to upgrade in 10 years". Turning this around, why is backwards
> >> compatibility still experimental after 10 years? I am involved with several
> >> Apache projects where we would love to upgrade from log4j 1 to log4j 2, and
> >> have been talking about it for _years_. However, we have not been able to
> >> easily do so because we actually care about operational cross-version
> >> compatibility for our users. On some of these projects we are still stuck
> >> on log4j 1.
> >> 
> >> I also support continuing releasing for log4j 1.x, and would volunteer some
> >> of my time to assist in the effort.
> >> 
> >> 
> >> On Tue, Dec 21, 2021 at 12:34 PM Matt Sicker  wrote:
> >> 
> >>> Nobody in the Logging PMC is blocking a release here. What we don’t want
> >>> is to falsely advertise that v1 is still under development. We already 
> >>> have
> >>> a huge increase in mailing list, PR, and other traffic ever since
> >>> Log4Shell, and if we resurrect v1, then it’ll quickly become impossible to
> >>> keep up with all the activity given the size of the PMC. If any 
> >>> non-trivial
> >>> work is to be done in v1, we’d prefer to see more than one person working
> >>> on that, especially if we want to add more PMC members to oversee v1 in 
> >>> the
> >>> first place.
> >>> 
> >>> And as for the v1 :: COBOL analogy, that’s not a bad comparison.
> >>> Basically, users who haven’t bothered to upgrade in 10 years will have to
> >>> end up paying astronomical costs for consultants who can still work on
> >>> ancient software 

Re: Looking for a champion: resurrect log4j 1.x

[Matt Sicker]

It would be nice if you filed any issues with Log4j2 about problems with 
migration. It would have been nice to hear about these issues back when v1 
stopped development, but this is the next best time to do so. The Log4j team 
are actively working to fill in any remaining gaps on backward compatibility; 
making new releases of EOL software with numerous implementation errors 
inherent to its architecture seems like going backwards.

—
Matt Sicker

> On Jan 8, 2022, at 13:45, Rohit Yadav  wrote:
> 
> Hi all, 
> 
> I agree and extend support for Andrew's remarks. Apache CloudStack too uses 
> log4j 1.x and our use case is simply a logging library that 1.x just 
> satisfies. The effort to migrate to 2.x is not quick, at least in our initial 
> investigation and a migration may likely require huge effort in testing.
> 
> Assuming this quick upgrade path doesn't exist, and I already read struggles 
> by other projects trying to migrate to 2.x - maintaining 1.x and doing a 
> 1.2.x release makes more sense than investing weeks in migration and testing 
> to 2.x, while maintaining the same artifact IDs. I'm up for volunteering and 
> supporting 1.x maintenance.
> 
> Regards, 
> Rohit Yadav 
> PMC, Apache CloudStack
> 
> On 2021/12/21 21:54:34 Andrew Purtell wrote:
>>> as for the v1 :: COBOL analogy, that’s not a bad comparison. Basically,
>> users who haven’t bothered to upgrade in 10 years will have to end up
>> paying astronomical costs for consultants who can still work on ancient
>> software effectively to help modify their systems.
>> 
>> I have to take some exception to this. If the log4j 2.x configuration files
>> were compatible _enough_ with 1.x then taking this position would be
>> understandable. However, because they are not compatible in the way that
>> users require -- and the backwards compatibility is still marked as
>> 'experimental', even -- it is not great to blame users "who haven't
>> bothered to upgrade in 10 years". Turning this around, why is backwards
>> compatibility still experimental after 10 years? I am involved with several
>> Apache projects where we would love to upgrade from log4j 1 to log4j 2, and
>> have been talking about it for _years_. However, we have not been able to
>> easily do so because we actually care about operational cross-version
>> compatibility for our users. On some of these projects we are still stuck
>> on log4j 1.
>> 
>> I also support continuing releasing for log4j 1.x, and would volunteer some
>> of my time to assist in the effort.
>> 
>> 
>> On Tue, Dec 21, 2021 at 12:34 PM Matt Sicker  wrote:
>> 
>>> Nobody in the Logging PMC is blocking a release here. What we don’t want
>>> is to falsely advertise that v1 is still under development. We already have
>>> a huge increase in mailing list, PR, and other traffic ever since
>>> Log4Shell, and if we resurrect v1, then it’ll quickly become impossible to
>>> keep up with all the activity given the size of the PMC. If any non-trivial
>>> work is to be done in v1, we’d prefer to see more than one person working
>>> on that, especially if we want to add more PMC members to oversee v1 in the
>>> first place.
>>> 
>>> And as for the v1 :: COBOL analogy, that’s not a bad comparison.
>>> Basically, users who haven’t bothered to upgrade in 10 years will have to
>>> end up paying astronomical costs for consultants who can still work on
>>> ancient software effectively to help modify their systems. Was Maven even
>>> widely used back when v1 was popular? Or were people still using a mix of
>>> make or Ant?
>>> --
>>> Matt Sicker
>>> 
 On Dec 21, 2021, at 07:13, Romain Manni-Bucau 
>>> wrote:
 
 Le mar. 21 déc. 2021 à 12:33, Enrico Olivelli  a
 écrit :
 
> Vladimir,
> I totally support this proposal.
> 
> Which are actually the steps we need to cut a release of log4j 1.x ?
> - establish an Apache project ?
> 
 
 1. Send a patch to apply on
 http://svn.apache.org/repos/asf/logging/log4j/trunk
 
 
> - do the fix
> 
 
 2. Get it applied
 
 
> - cut a release
> 
> Can this be done inside another Apache Project who "adopts" the log4j
> sources if the Logging Project doesn't want to do it ?
> 
 
 The PMC of log4j2 is logging project so it should be done there, if not
>>> the
 project can be forked inside Apache but should change of package until we
 get the perms to reuse the same one which means likely as much work as
>>> just
 getting it done at logging project so hope it is not needed ;).
 
 
> 
> Enrico
> 
> 
> Il giorno mar 21 dic 2021 alle ore 08:36 Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> ha scritto:
> 
>>> Just wondering, is it even fulfilling the criteria of incubation?
>> 
>> I believe, the world does not need "active development in log4j 1.x"
>> nowadays.
>> What everybody needs from log4j 1.x is to fix security issues, fix

Re: Looking for a champion: resurrect log4j 1.x

[Rohit Yadav]

Hi all, 

I agree and extend support for Andrew's remarks. Apache CloudStack too uses 
log4j 1.x and our use case is simply a logging library that 1.x just satisfies. 
The effort to migrate to 2.x is not quick, at least in our initial 
investigation and a migration may likely require huge effort in testing.

Assuming this quick upgrade path doesn't exist, and I already read struggles by 
other projects trying to migrate to 2.x - maintaining 1.x and doing a 1.2.x 
release makes more sense than investing weeks in migration and testing to 2.x, 
while maintaining the same artifact IDs. I'm up for volunteering and supporting 
1.x maintenance.

Regards, 
Rohit Yadav 
PMC, Apache CloudStack

On 2021/12/21 21:54:34 Andrew Purtell wrote:
> > as for the v1 :: COBOL analogy, that’s not a bad comparison. Basically,
> users who haven’t bothered to upgrade in 10 years will have to end up
> paying astronomical costs for consultants who can still work on ancient
> software effectively to help modify their systems.
> 
> I have to take some exception to this. If the log4j 2.x configuration files
> were compatible _enough_ with 1.x then taking this position would be
> understandable. However, because they are not compatible in the way that
> users require -- and the backwards compatibility is still marked as
> 'experimental', even -- it is not great to blame users "who haven't
> bothered to upgrade in 10 years". Turning this around, why is backwards
> compatibility still experimental after 10 years? I am involved with several
> Apache projects where we would love to upgrade from log4j 1 to log4j 2, and
> have been talking about it for _years_. However, we have not been able to
> easily do so because we actually care about operational cross-version
> compatibility for our users. On some of these projects we are still stuck
> on log4j 1.
> 
> I also support continuing releasing for log4j 1.x, and would volunteer some
> of my time to assist in the effort.
> 
> 
> On Tue, Dec 21, 2021 at 12:34 PM Matt Sicker  wrote:
> 
> > Nobody in the Logging PMC is blocking a release here. What we don’t want
> > is to falsely advertise that v1 is still under development. We already have
> > a huge increase in mailing list, PR, and other traffic ever since
> > Log4Shell, and if we resurrect v1, then it’ll quickly become impossible to
> > keep up with all the activity given the size of the PMC. If any non-trivial
> > work is to be done in v1, we’d prefer to see more than one person working
> > on that, especially if we want to add more PMC members to oversee v1 in the
> > first place.
> >
> > And as for the v1 :: COBOL analogy, that’s not a bad comparison.
> > Basically, users who haven’t bothered to upgrade in 10 years will have to
> > end up paying astronomical costs for consultants who can still work on
> > ancient software effectively to help modify their systems. Was Maven even
> > widely used back when v1 was popular? Or were people still using a mix of
> > make or Ant?
> > --
> > Matt Sicker
> >
> > > On Dec 21, 2021, at 07:13, Romain Manni-Bucau 
> > wrote:
> > >
> > > Le mar. 21 déc. 2021 à 12:33, Enrico Olivelli  a
> > > écrit :
> > >
> > >> Vladimir,
> > >> I totally support this proposal.
> > >>
> > >> Which are actually the steps we need to cut a release of log4j 1.x ?
> > >> - establish an Apache project ?
> > >>
> > >
> > > 1. Send a patch to apply on
> > > http://svn.apache.org/repos/asf/logging/log4j/trunk
> > >
> > >
> > >> - do the fix
> > >>
> > >
> > > 2. Get it applied
> > >
> > >
> > >> - cut a release
> > >>
> > >> Can this be done inside another Apache Project who "adopts" the log4j
> > >> sources if the Logging Project doesn't want to do it ?
> > >>
> > >
> > > The PMC of log4j2 is logging project so it should be done there, if not
> > the
> > > project can be forked inside Apache but should change of package until we
> > > get the perms to reuse the same one which means likely as much work as
> > just
> > > getting it done at logging project so hope it is not needed ;).
> > >
> > >
> > >>
> > >> Enrico
> > >>
> > >>
> > >> Il giorno mar 21 dic 2021 alle ore 08:36 Vladimir Sitnikov <
> > >> sitnikov.vladi...@gmail.com> ha scritto:
> > >>
> >  Just wondering, is it even fulfilling the criteria of incubation?
> > >>>
> > >>> I believe, the world does not need "active development in log4j 1.x"
> > >>> nowadays.
> > >>> What everybody needs from log4j 1.x is to fix security issues, fix
> > >>> outstanding issues (if any),
> > >>> keep the project buildable (e.g. avoid using outdated build systems),
> > >> etc.
> > >>>
> >  it doesn't seem that sustainability is proven.
> > >>>
> > >>> The problem is log4j 1.x is like COBOL of logging. There are apps that
> > >> are
> > >>> just stuck with log4j 1.x.
> > >>> The proof of sustainability is that lots of existing apps will never
> > >>> upgrade to 2.x because 2.x is incompatible.
> > >>> If the compatibility layer of 2.x would be improved to handle 99.999%
> > of
> > 

Re: Looking for a champion: resurrect log4j 1.x

[Christian Grobmeier]

Hello,

I just came across this thread - same as Ralph, I currently don't mentor any 
podlings. However, I am still on the Logging PMC.

On Thu, Dec 23, 2021, at 07:05, Vladimir Sitnikov wrote:
> Ralph>I was busy
>
> The world is on fire with log4j, so if you have no time left for 1.x, then,
> please, just let others do the maintenance.

You have been constantly treating others with disrespect. 

Nobody of us committed any time for log4j1 since 2012, and since 2015 it is 
EOL. Nobody of us even thought about giving any time to log4j1 until you came 
up on this list. I think it is fair to say the world is on fire with log4j2 BUT 
NOT with log4j1.

There is no new security issues with log4j1. Instead we retired log4j1 for many 
reasons, including some multithreading issues which require heavy architectural 
changes - which we then fixed with log4j2. Nobody was able to fix it back then.

Maybe I have missed something, but we never accepted a single podling for just 
one release, with one committer, with the original PMC opposing this step. And 
this for two security issues which are 10 years old which are not comparable to 
the ones we found in log4j2.

I recommend looking at the Logging Chairs statement for details if interested 
which will be sent soon.

Also, I don't think Cobol and Log4j 1 match up. 

That being said, the PMCs job - especially those people dealing with this issue 
- has been excellent so far, and this email thread looks like some of us were 
blocking all the time. That's not true and is a wrong impression. We just 
haven't heard good arguments for resurrecting log4j1.

Cheers
Christian



>
> Ralph>My recollection was me saying if I had the code in a git repo getting
> it into a GitHub repo would be easy.
>
> I do not want to dilute "svn -> git" question any further, so, if you have
> time (apparently, you do respond on logging and here),
> consider answering at https://issues.apache.org/jira/browse/LOG4J2-3272
>
> ---
>
> Ralph, my response was
> https://lists.apache.org/thread/jzym3z270jqr84m8o4m7pxlmpk8frr4z
> Literally, you have **nothing** to do except blessing the migration in
> order to get Git and GitHub open for log4j 1.x .
>
> You even ignored "[VOTE] Move log4j 1.x from SVN to Git..."
> https://lists.apache.org/thread/ssbdg44gy7txzl16xxd097t7orco52g2
>
> You still keep asking "if git repo exists or not". Who cares if git repo
> exists?
> I offer you help with getting the things done, yet you ask questions as if
> I ask you to do the work.
>
> Vladimir

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Looking for a champion: resurrect log4j 1.x

[Vladimir Sitnikov]

Ralph>I was busy

The world is on fire with log4j, so if you have no time left for 1.x, then,
please, just let others do the maintenance.

Ralph>My recollection was me saying if I had the code in a git repo getting
it into a GitHub repo would be easy.

I do not want to dilute "svn -> git" question any further, so, if you have
time (apparently, you do respond on logging and here),
consider answering at https://issues.apache.org/jira/browse/LOG4J2-3272

---

Ralph, my response was
https://lists.apache.org/thread/jzym3z270jqr84m8o4m7pxlmpk8frr4z
Literally, you have **nothing** to do except blessing the migration in
order to get Git and GitHub open for log4j 1.x .

You even ignored "[VOTE] Move log4j 1.x from SVN to Git..."
https://lists.apache.org/thread/ssbdg44gy7txzl16xxd097t7orco52g2

You still keep asking "if git repo exists or not". Who cares if git repo
exists?
I offer you help with getting the things done, yet you ask questions as if
I ask you to do the work.

Vladimir

Re: Looking for a champion: resurrect log4j 1.x

[Duo Zhang]

OK, thank you for the feedback.

Will open issues and also discuss threads on the mailing list for these
things.

Ralph Goers  于2021年12月23日周四 08:10写道：

>
>
> > On Dec 21, 2021, at 9:22 PM, 张铎(Duo Zhang) 
> wrote:
> >
> > But in my experience, first, the log4j12 bridge is not perfect. For
> > example, since hadoop is still on log4j 1.x, I need to add log4j12 bridge
> > dependency if I want to run UTs based on hadoop mini cluster, and then I
> > need to manually copy some code from log4j1 in order to make it work,
> this
> > is an example
> >
> >
> https://github.com/apache/hbase/blob/master/hbase-logging/src/test/java/org/apache/log4j/FileAppender.java
> >
> > I know in the bridge you will create log4j2 appender instead when reading
> > the configuration file of log4j1, but since the appenders in log4j1 lack
> of
> > some abilities, it is common that lots of projects will implement their
> own
> > appender, I think we should take care of these usages and make them
> migrate
> > smoothly.
>
> I do not know if you are aware but the experimental support we added a few
> releases ago should
> be able to use Log4j 1 Appenders in Log4j2. It is experimental simply
> because we have no idea what wild
> and crazy things uses are relying on in Log4j 1 since nothing was private.
> We need user feedback.
>
> >
> > And then, while fully migrating to log4j2, there is another annoying
> > problem, the
> >
> > log4j.rootLogger=INFO,console
> >
> > grammar is gone! It is used among almost all the projects I've seen, and
> we
> > just drop the support for it!
>
> Again, support for Log4j 1 configuration files is part of the experimental
> support. We finally received
> our first bug report on it so someone is using it.
>
> Ralph
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Looking for a champion: resurrect log4j 1.x

[Ralph Goers]

> On Dec 22, 2021, at 12:35 AM, Vladimir Sitnikov  
> wrote:
> 
> 
> I already asked Logging PMC to enable Git and GitHub for 1.x, and they
> rejected it:
> https://lists.apache.org/thread/ssbdg44gy7txzl16xxd097t7orco52g2

My recollection was me saying if I had the code in a git repo getting it into a 
GitHub repo would be easy. 
But I wasn’t going to do the work. But it appears the code is in Gitbox. If so, 
getting it into an updatable 
GitHub repo should be easy - except the name you probably want to use is the 
one used by Gitbox.

We’ve also asked what your plans would be for all the issues that are in 
Bugzilla. It seems you would rather 
use Jira or GitHub issues. I don’t blame you there. But will you just ignore 
all those old problems? 
I don’t recall getting an answer. But maybe you did. I was busy.

Ralph


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Looking for a champion: resurrect log4j 1.x

[Ralph Goers]

> On Dec 21, 2021, at 10:24 PM, Vladimir Sitnikov  
> wrote:
> 
> Matt>Nobody in the Logging PMC is blocking a release here.
> 
> Matt, thanks for the reply, however, it is false :(
> I see you are positive, however, many more replies were quite negative.
> 
> Ralph Goers says: "We’ve stated several times that we don’t think
> resurrecting Log4j 1.x permanently is a good idea."
> https://lists.apache.org/thread/vz80p3v78xgposon3pcxbnb9729snnxt
> 
> Gary Gregory says: "As I've stated before, IF there is a 1.2.18, it should
> ONLY be for CVEs,"
> https://lists.apache.org/thread/53h130p0kdkspn4kj2hq39vkgpyzgvp7
> 
> They both are on Logging PMC, and they both have negative opinions on
> making progress with v1.
> I do not really understand what "ONLY be for CVEs" means (e.g. does it
> allow upgrading from Maven2 to Maven3?),
> but I do not want to get accidentally blocked by "oh, this change is not
> allowed because it is not a CVE fix".

Of course we have opinions. But me saying I don’t think it is a good idea 
doesn’t mean 
“No, it isn’t going to happen”.  I’ve said I think lots of things are bad ideas 
and then 
changed my mind. But the emphasis here should really be on getting consensus 
from 
those who are trying to do work on Log4j 1.x. Do they just want a 1.2.18 
release or a 
continuing sub-project. I know you are very vocal about wanting a continuing 
sub-project 
but I’ve not really heard anybody else say they are in it for the long haul.

Ralph
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Looking for a champion: resurrect log4j 1.x

[Ralph Goers]

> On Dec 21, 2021, at 9:22 PM, 张铎(Duo Zhang)  wrote:
> 
> But in my experience, first, the log4j12 bridge is not perfect. For
> example, since hadoop is still on log4j 1.x, I need to add log4j12 bridge
> dependency if I want to run UTs based on hadoop mini cluster, and then I
> need to manually copy some code from log4j1 in order to make it work, this
> is an example
> 
> https://github.com/apache/hbase/blob/master/hbase-logging/src/test/java/org/apache/log4j/FileAppender.java
> 
> I know in the bridge you will create log4j2 appender instead when reading
> the configuration file of log4j1, but since the appenders in log4j1 lack of
> some abilities, it is common that lots of projects will implement their own
> appender, I think we should take care of these usages and make them migrate
> smoothly.

I do not know if you are aware but the experimental support we added a few 
releases ago should 
be able to use Log4j 1 Appenders in Log4j2. It is experimental simply because 
we have no idea what wild 
and crazy things uses are relying on in Log4j 1 since nothing was private. We 
need user feedback.

> 
> And then, while fully migrating to log4j2, there is another annoying
> problem, the
> 
> log4j.rootLogger=INFO,console
> 
> grammar is gone! It is used among almost all the projects I've seen, and we
> just drop the support for it!

Again, support for Log4j 1 configuration files is part of the experimental 
support. We finally received 
our first bug report on it so someone is using it.

Ralph
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Looking for a champion: resurrect log4j 1.x

[Ralph Goers]

I’m sorry, I was just directed to this thread. I don’t read my incubator emails 
every day since I am not mentoring any podlings at the moment.

There seems to be some disconnect with the facts. From my viewpoint they are:

An email came in asking if it would be possible to put out a new 1.2.18 release 
to address the outstanding CVEs. Our response was that we 
were totally focused on 2.x, don’t have a lot of experience building 1.x but 
would be happy to help release that if it met the PMCs expectations.

A pull request then arrived - I believe https://github.com/apache/log4j/pull/16 
- that was objected to by one of our PMC members as it deletes 
a bunch of classes rather than fixing them in a manner similar to what we did 
for Log4j 2.

I noticed that there seemed to be a disconnect between some of the posters. 
Some just wanted to get 1.2.18 published as originally proposed 
while others seemed to want it to continue on. As there currently is no Log4j 1 
community I asked which option they were after and suggested 
that if they wanted to develop a community that the incubator is where that 
happens with Logging Services as the sponsor. If a community 
develops it would be expected that graduation would be as a subproject of the 
Logging Services Project. That seemed to make some 
unhappy as any PMC member could veto commits in the Log4j 1 work.

As far as I am concerned we never really got an answer to
1) Is this a one and done?
2) Is there are real community to support Log4j 1? 
3) There are major flaws in Log4j 1.x’s architecture which is why SLF4J/Logback 
and Log4j 2 came to be. Will an attempt be made to address 
those without breaking compatibility?
4) Does this community care about compatibility? Simply removing classes is not 
user friendly.

To top it off this discussion was going on while the whole Logging Services PMC 
was overwhelmed with security emails, users asking for help, 
and the PMC trying to get patch releases out. It was a poor choice of timing to 
try to have this discussion during that frenzy.

In short, we don’t object to either a 1.2.18 release or reactivating Log4j 1. 
What we don’t want is a release of Log4j 1 along with a misconception 
that it is being supported again when it is not. We don’t want releases of 
Log4j 1 that do more harm than good.

Sorry for the long post.

Ralph


> On Dec 20, 2021, at 12:26 AM, Vladimir Sitnikov  
> wrote:
> 
> Hi,
> 
> I want to resurrect log4j 1.x to fix well-known security issues.
> I'm looking for the champion and committers.
> 
> log4j 1.x is a wildly used logging library, so releasing a secured version
> would silence CVE warnings
> all over the world, and it would enable users to focus on more relevant
> tasks than "upgrading from log4j1 to log4j2".
> 
> I do not expect active log4j1 development, however, I would strongly focus
> on fixing the security issues.
> 
> Unfortunately, there are lots of applications that can't easily upgrade to
> log4j2, and they are exposed to security issues.
> I did try my best cooperating with the current logging PMC, and it looks
> like they
> are not interested in fixing 1.x (see [1], [2], [3], [4])
> 
> I'm a member of PMC on Apache JMeter and Apache Calcite projects, so
> I am familiar with the way Apache projects are governed.
> 
> [1]: https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5
> [2]: https://lists.apache.org/thread/hq2m11f1w9yp031r5f65b9h4ym2zy1kc
> [3]: https://lists.apache.org/thread/tw172svxt1q6wds7lt9szyjw2sxjf34n
> [4]: https://lists.apache.org/thread/y89v84okzs76g2yl760vx5yc0w1y4yd8
> 
> Vladimir


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Looking for a champion: resurrect log4j 1.x

[Matt Sicker]

The Commons approach isn’t likely to work. Besides sharing several PMC members, 
it already deprecated Commons Logging in favor of Log4j2 as a logging API.

—
Matt Sicker

> On Dec 22, 2021, at 12:59, Dave Fisher  wrote:
> 
> Have the initial committers for this effort been identified?
> 
>> On Dec 22, 2021, at 10:28 AM, Vladimir Sitnikov 
>>  wrote:
>> 
>> Matt>Attaching patches to Jira is exactly how v1 was developed back in the
>> day. V2 did it for some time as well before migrating to git
>> 
>> Matt, let us please refrain from off-topic discussions here? (at the end of
>> the day, this is "Looking for a champion" thread)
> 
> IMO - this effort would not benefit from Incubation. Incubation will slow 
> down this effort as graduation requirements won’t fit a small and compact 
> community that has in mind a singular effort.
> 
> Alternatives ways to organize this:
> 
> (1) Get at least 3 Apache Members together (IPMC members are almost all 
> Apache Members) and make a Board Resolution to form a new PMC. Fork the 
> resources, or Logging turns them over.
> 
> (2) Work within the Logging PMC
> 
> (3) Ask the Commons PMC if they would take back Log4J 1.x.
> 
> Regards,
> Dave
> 
>> 
>> If you have objections or comments regarding LOG4J2-3272, would you please
>> comment there?
>> (I truly do not understand why is it important to know how v1 or v2
>> accepted fixes back in the days)
>> 
>> Vladimir
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

Re: Looking for a champion: resurrect log4j 1.x

[Dave Fisher]

Have the initial committers for this effort been identified?

> On Dec 22, 2021, at 10:28 AM, Vladimir Sitnikov  
> wrote:
> 
> Matt>Attaching patches to Jira is exactly how v1 was developed back in the
> day. V2 did it for some time as well before migrating to git
> 
> Matt, let us please refrain from off-topic discussions here? (at the end of
> the day, this is "Looking for a champion" thread)

IMO - this effort would not benefit from Incubation. Incubation will slow down 
this effort as graduation requirements won’t fit a small and compact community 
that has in mind a singular effort.

Alternatives ways to organize this:

(1) Get at least 3 Apache Members together (IPMC members are almost all Apache 
Members) and make a Board Resolution to form a new PMC. Fork the resources, or 
Logging turns them over.

(2) Work within the Logging PMC

(3) Ask the Commons PMC if they would take back Log4J 1.x.

Regards,
Dave

> 
> If you have objections or comments regarding LOG4J2-3272, would you please
> comment there?
> (I truly do not understand why is it important to know how v1 or v2
> accepted fixes back in the days)
> 
> Vladimir


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Looking for a champion: resurrect log4j 1.x

[Vladimir Sitnikov]

Matt>Attaching patches to Jira is exactly how v1 was developed back in the
day. V2 did it for some time as well before migrating to git

Matt, let us please refrain from off-topic discussions here? (at the end of
the day, this is "Looking for a champion" thread)

If you have objections or comments regarding LOG4J2-3272, would you please
comment there?
(I truly do not understand why is it important to know how v1 or v2
accepted fixes back in the days)

Vladimir

Re: Looking for a champion: resurrect log4j 1.x

[Matt Sicker]

Attaching patches to Jira is exactly how v1 was developed back in the day. V2 
did it for some time as well before migrating to git.

—
Matt Sicker

> On Dec 22, 2021, at 01:42, Vladimir Sitnikov  
> wrote:
> 
> Romain,
> 
> Romain>for now the thread is looking for options which are not needed from
> my window
> 
> It was the Logging PMC team who suggested I should re-incubate log4j 1.x.
> 
> Romain>1. where is the patch needed to fix the desired CVE? - must be
> compatible
> with current SVN trunk
> 
> The current SVN trunk is NOT buildable.
> It uses outdated build tools, so build system healing
> is needed before ANY other patches.
> 
> Romain>2. please attach it to a ticket
> 
> I have just created https://issues.apache.org/jira/browse/LOG4J2-3272
> "Enable Git and GitHub for log4j 1.2 repository"
> 
> Every patch to 1.x must be well-tested, so attaching patch files to JIRA
> is a recipe for disaster.
> 
> I already asked Logging PMC to enable Git and GitHub for 1.x, and they
> rejected it:
> https://lists.apache.org/thread/ssbdg44gy7txzl16xxd097t7orco52g2
> 
> I do not see why filing the same thing as JIRA would work any better than
> sending mail to dev@logging list.
> 
> Vladimir

Re: Looking for a champion: resurrect log4j 1.x

[Romain Manni-Bucau]

I know Vladimir but let's do things in order, if we move in all ways it
will fail.
Incubating log4j1 will fail as I epxlained - not even sure incubator would
let it be incubated since project is official dead for everybody and can
only get security fixes (incubator is to ensure you can build a community
and comply to ASF, for log4j1 it is out of topic).
If current logging PMC does not want to release they will have the choice
to donate the group for an external project or let the release be done. For
that last point you need at least 3 PMC voting and if current one does not
want to do it they can always add new PMC member willing to release -
plenty are easily found, even just in this thread.

So please stick to the normal plan:

1. do the work
2. share it properly (one feature per patch/ticket, not all at once is what
I mean here ;))
3. solve the "how to release"

To be honest speaking of 3 without having 1 and 2 is pointless.

Just to push what I just said: we had the same in maven (surefire) and the
release had been done finally so back to keyboard if anyone wants it to
happen IMHO, no need to look for future issues before they are actually
actual.

Romain

Le mer. 22 déc. 2021 à 08:42, Vladimir Sitnikov 
a écrit :

> Romain,
>
> Romain>for now the thread is looking for options which are not needed from
> my window
>
> It was the Logging PMC team who suggested I should re-incubate log4j 1.x.
>
> Romain>1. where is the patch needed to fix the desired CVE? - must be
> compatible
> with current SVN trunk
>
> The current SVN trunk is NOT buildable.
> It uses outdated build tools, so build system healing
> is needed before ANY other patches.
>
> Romain>2. please attach it to a ticket
>
> I have just created https://issues.apache.org/jira/browse/LOG4J2-3272
> "Enable Git and GitHub for log4j 1.2 repository"
>
> Every patch to 1.x must be well-tested, so attaching patch files to JIRA
> is a recipe for disaster.
>
> I already asked Logging PMC to enable Git and GitHub for 1.x, and they
> rejected it:
> https://lists.apache.org/thread/ssbdg44gy7txzl16xxd097t7orco52g2
>
> I do not see why filing the same thing as JIRA would work any better than
> sending mail to dev@logging list.
>
> Vladimir
>

Re: Looking for a champion: resurrect log4j 1.x

[Vladimir Sitnikov]

>I would propose to talk with logging PMC first

I did exactly that, and they did not listen. They have no will to keep
releasing 1.x versions.
At the same time, they do not allow others to release log4j:log4j:1.x
versions.

I'm waiting for the response by Logging PMC chair Ron once again:
https://lists.apache.org/thread/sgpc57tsl6wlklz8z682jmv4zf0l70vz

Vladimir

Re: Looking for a champion: resurrect log4j 1.x

[Vladimir Sitnikov]

Romain,

Romain>for now the thread is looking for options which are not needed from
my window

It was the Logging PMC team who suggested I should re-incubate log4j 1.x.

Romain>1. where is the patch needed to fix the desired CVE? - must be
compatible
with current SVN trunk

The current SVN trunk is NOT buildable.
It uses outdated build tools, so build system healing
is needed before ANY other patches.

Romain>2. please attach it to a ticket

I have just created https://issues.apache.org/jira/browse/LOG4J2-3272
"Enable Git and GitHub for log4j 1.2 repository"

Every patch to 1.x must be well-tested, so attaching patch files to JIRA
is a recipe for disaster.

I already asked Logging PMC to enable Git and GitHub for 1.x, and they
rejected it:
https://lists.apache.org/thread/ssbdg44gy7txzl16xxd097t7orco52g2

I do not see why filing the same thing as JIRA would work any better than
sending mail to dev@logging list.

Vladimir

Re: Looking for a champion: resurrect log4j 1.x

[JB Onofré]

Agree with Romain. Let’s just take concrete actions: I would propose to talk 
with logging PMC first (they can provide their preferences). 

It’s really amazing how we can create endless thread for simple/concrete topics 
;)

Regards 
JB

> Le 22 déc. 2021 à 08:17, Romain Manni-Bucau  a écrit :
> 
> ok, so let's try to not create an endless thread:
> 
> 1. where is the patch needed to fix the desired CVE? - must be compatible
> with current svn trunk
> 2. please attach it to a ticket (or multiple if there are multiple fixes)
> like LOG4J2-3219
> 3. if it does not get applied and PMC is opposed to get it applied let's
> create a thread about it as being an issue and look for options but for now
> the thread is looking for options which are not needed from my window
> 
> Hope it helps ot move the ball forward
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
> Le mer. 22 déc. 2021 à 06:24, Vladimir Sitnikov 
> a écrit :
> 
>> Matt>Nobody in the Logging PMC is blocking a release here.
>> 
>> Matt, thanks for the reply, however, it is false :(
>> I see you are positive, however, many more replies were quite negative.
>> 
>> Ralph Goers says: "We’ve stated several times that we don’t think
>> resurrecting Log4j 1.x permanently is a good idea."
>> https://lists.apache.org/thread/vz80p3v78xgposon3pcxbnb9729snnxt
>> 
>> Gary Gregory says: "As I've stated before, IF there is a 1.2.18, it should
>> ONLY be for CVEs,"
>> https://lists.apache.org/thread/53h130p0kdkspn4kj2hq39vkgpyzgvp7
>> 
>> They both are on Logging PMC, and they both have negative opinions on
>> making progress with v1.
>> I do not really understand what "ONLY be for CVEs" means (e.g. does it
>> allow upgrading from Maven2 to Maven3?),
>> but I do not want to get accidentally blocked by "oh, this change is not
>> allowed because it is not a CVE fix".
>> 
>> Matt>What we don’t want is to falsely advertise that v1 is still under
>> development
>> 
>> For instance, I do want to support new versions of v1.
>> If Logging PMC does not want advertise v1, that is fine. Would you donate
>> log4j 1.x code
>> to Incubator or to another PMC?
>> 
>> Matt>if we resurrect v1, then it’ll quickly become impossible to keep up
>> with all the activity given the size of the PMC
>> 
>> log4j v1 and log4j v2 are completely different products sharing the same
>> name.
>> So it won't be that surprising to have different people working on them.
>> 
>> Adding PMC members is one of the solutions. Donating the code to another
>> PMC is another solution.
>> 
>> I agree you have an unusual traffic spike now, however, multiple members of
>> Logging PMC do respond regarding v1,
>> and the overall intention is "Logging PMC is not interested in v1".
>> 
>> That is not something I want spending time on.
>> If I want to get v1 CVE fixed, I want to get it done and released. I do not
>> want to spend my time on "evangelizing v2, v3, or whatever".
>> 
>> Matt>we’d prefer to see more than one person working on that,
>> Matt>especially if we want to add more PMC members to oversee v1 in the
>> first place
>> 
>> Matt, this case is really unusual. Do you really want *multiple*
>> individuals to *actively* contribute to log4j v1
>> in order to add them to v1 PMC?
>> That is impossible. There's not much work to do in v1. There's no way I can
>> improve v1 code in a consistent and non-trivial way.
>> 
>> You should not be sitting and waiting for new v1 contributions to come.
>> 
>> So I would say it is not fair to say "there's not enough Logging PMC".
>> What needs to be done to add PMC members for v1?
>> 
>> Matt>users who haven’t bothered to upgrade in 10 years will have to end up
>> paying astronomical costs
>> 
>> There **is** possibility to maintain COBOL.
>> Currently, external contributions, including CVE fixes, are literally
>> blocked.
>> 
>> Matt>Or were people still using a mix of make or Ant?
>> 
>> People use Ant a lot, and there are new Ant releases:
>> https://ant.apache.org/antnews.html
>> 
>> Vladimir
>> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Looking for a champion: resurrect log4j 1.x

[Romain Manni-Bucau]

ok, so let's try to not create an endless thread:

1. where is the patch needed to fix the desired CVE? - must be compatible
with current svn trunk
2. please attach it to a ticket (or multiple if there are multiple fixes)
like LOG4J2-3219
3. if it does not get applied and PMC is opposed to get it applied let's
create a thread about it as being an issue and look for options but for now
the thread is looking for options which are not needed from my window

Hope it helps ot move the ball forward

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 22 déc. 2021 à 06:24, Vladimir Sitnikov 
a écrit :

> Matt>Nobody in the Logging PMC is blocking a release here.
>
> Matt, thanks for the reply, however, it is false :(
> I see you are positive, however, many more replies were quite negative.
>
> Ralph Goers says: "We’ve stated several times that we don’t think
> resurrecting Log4j 1.x permanently is a good idea."
> https://lists.apache.org/thread/vz80p3v78xgposon3pcxbnb9729snnxt
>
> Gary Gregory says: "As I've stated before, IF there is a 1.2.18, it should
> ONLY be for CVEs,"
> https://lists.apache.org/thread/53h130p0kdkspn4kj2hq39vkgpyzgvp7
>
> They both are on Logging PMC, and they both have negative opinions on
> making progress with v1.
> I do not really understand what "ONLY be for CVEs" means (e.g. does it
> allow upgrading from Maven2 to Maven3?),
> but I do not want to get accidentally blocked by "oh, this change is not
> allowed because it is not a CVE fix".
>
> Matt>What we don’t want is to falsely advertise that v1 is still under
> development
>
> For instance, I do want to support new versions of v1.
> If Logging PMC does not want advertise v1, that is fine. Would you donate
> log4j 1.x code
> to Incubator or to another PMC?
>
> Matt>if we resurrect v1, then it’ll quickly become impossible to keep up
> with all the activity given the size of the PMC
>
> log4j v1 and log4j v2 are completely different products sharing the same
> name.
> So it won't be that surprising to have different people working on them.
>
> Adding PMC members is one of the solutions. Donating the code to another
> PMC is another solution.
>
> I agree you have an unusual traffic spike now, however, multiple members of
> Logging PMC do respond regarding v1,
> and the overall intention is "Logging PMC is not interested in v1".
>
> That is not something I want spending time on.
> If I want to get v1 CVE fixed, I want to get it done and released. I do not
> want to spend my time on "evangelizing v2, v3, or whatever".
>
> Matt>we’d prefer to see more than one person working on that,
> Matt>especially if we want to add more PMC members to oversee v1 in the
> first place
>
> Matt, this case is really unusual. Do you really want *multiple*
> individuals to *actively* contribute to log4j v1
> in order to add them to v1 PMC?
> That is impossible. There's not much work to do in v1. There's no way I can
> improve v1 code in a consistent and non-trivial way.
>
> You should not be sitting and waiting for new v1 contributions to come.
>
> So I would say it is not fair to say "there's not enough Logging PMC".
> What needs to be done to add PMC members for v1?
>
> Matt>users who haven’t bothered to upgrade in 10 years will have to end up
> paying astronomical costs
>
> There **is** possibility to maintain COBOL.
> Currently, external contributions, including CVE fixes, are literally
> blocked.
>
> Matt>Or were people still using a mix of make or Ant?
>
> People use Ant a lot, and there are new Ant releases:
> https://ant.apache.org/antnews.html
>
> Vladimir
>

Re: Looking for a champion: resurrect log4j 1.x

[Vladimir Sitnikov]

Matt>Nobody in the Logging PMC is blocking a release here.

Matt, thanks for the reply, however, it is false :(
I see you are positive, however, many more replies were quite negative.

Ralph Goers says: "We’ve stated several times that we don’t think
resurrecting Log4j 1.x permanently is a good idea."
https://lists.apache.org/thread/vz80p3v78xgposon3pcxbnb9729snnxt

Gary Gregory says: "As I've stated before, IF there is a 1.2.18, it should
ONLY be for CVEs,"
https://lists.apache.org/thread/53h130p0kdkspn4kj2hq39vkgpyzgvp7

They both are on Logging PMC, and they both have negative opinions on
making progress with v1.
I do not really understand what "ONLY be for CVEs" means (e.g. does it
allow upgrading from Maven2 to Maven3?),
but I do not want to get accidentally blocked by "oh, this change is not
allowed because it is not a CVE fix".

Matt>What we don’t want is to falsely advertise that v1 is still under
development

For instance, I do want to support new versions of v1.
If Logging PMC does not want advertise v1, that is fine. Would you donate
log4j 1.x code
to Incubator or to another PMC?

Matt>if we resurrect v1, then it’ll quickly become impossible to keep up
with all the activity given the size of the PMC

log4j v1 and log4j v2 are completely different products sharing the same
name.
So it won't be that surprising to have different people working on them.

Adding PMC members is one of the solutions. Donating the code to another
PMC is another solution.

I agree you have an unusual traffic spike now, however, multiple members of
Logging PMC do respond regarding v1,
and the overall intention is "Logging PMC is not interested in v1".

That is not something I want spending time on.
If I want to get v1 CVE fixed, I want to get it done and released. I do not
want to spend my time on "evangelizing v2, v3, or whatever".

Matt>we’d prefer to see more than one person working on that,
Matt>especially if we want to add more PMC members to oversee v1 in the
first place

Matt, this case is really unusual. Do you really want *multiple*
individuals to *actively* contribute to log4j v1
in order to add them to v1 PMC?
That is impossible. There's not much work to do in v1. There's no way I can
improve v1 code in a consistent and non-trivial way.

You should not be sitting and waiting for new v1 contributions to come.

So I would say it is not fair to say "there's not enough Logging PMC".
What needs to be done to add PMC members for v1?

Matt>users who haven’t bothered to upgrade in 10 years will have to end up
paying astronomical costs

There **is** possibility to maintain COBOL.
Currently, external contributions, including CVE fixes, are literally
blocked.

Matt>Or were people still using a mix of make or Ant?

People use Ant a lot, and there are new Ant releases:
https://ant.apache.org/antnews.html

Vladimir

Re: Looking for a champion: resurrect log4j 1.x

[Dave Fisher]

Sent from my iPhone

> On Dec 21, 2021, at 5:13 AM, Romain Manni-Bucau  wrote:
> 
> Le mar. 21 déc. 2021 à 12:33, Enrico Olivelli  a
> écrit :
> 
>> Vladimir,
>> I totally support this proposal.
>> 
>> Which are actually the steps we need to cut a release of log4j 1.x ?
>> - establish an Apache project ?
>> 
> 
> 1. Send a patch to apply on
> http://svn.apache.org/repos/asf/logging/log4j/trunk
> 
> 
>> - do the fix
>> 
> 
> 2. Get it applied
> 
> 
>> - cut a release
>> 
>> Can this be done inside another Apache Project who "adopts" the log4j
>> sources if the Logging Project doesn't want to do it ?
>> 
> 
> The PMC of log4j2 is logging project so it should be done there, if not the
> project can be forked inside Apache but should change of package until we
> get the perms to reuse the same one which means likely as much work as just
> getting it done at logging projec
> so hope it is not needed ;).
> 

If you think this is a problem then Apache members could ask the board to 
establish a new PMC to support log4j 1 including reusing the package.

Regards?
Dave
> 
>> 
>> Enrico
>> 
>> 
>> Il giorno mar 21 dic 2021 alle ore 08:36 Vladimir Sitnikov <
>> sitnikov.vladi...@gmail.com> ha scritto:
>> 
 Just wondering, is it even fulfilling the criteria of incubation?
>>> 
>>> I believe, the world does not need "active development in log4j 1.x"
>>> nowadays.
>>> What everybody needs from log4j 1.x is to fix security issues, fix
>>> outstanding issues (if any),
>>> keep the project buildable (e.g. avoid using outdated build systems),
>> etc.
>>> 
 it doesn't seem that sustainability is proven.
>>> 
>>> The problem is log4j 1.x is like COBOL of logging. There are apps that
>> are
>>> just stuck with log4j 1.x.
>>> The proof of sustainability is that lots of existing apps will never
>>> upgrade to 2.x because 2.x is incompatible.
>>> If the compatibility layer of 2.x would be improved to handle 99.999% of
>>> apps,
>>> then we could indeed move 1.x to the attic.
>>> 
>>> The Incubator Cookbook says:
 The ASF provides software for the public good,
>>> 
>>> As I described, log4j 2.x is not a direct replacement for log4j 1.x, and
>>> there are **lots** of applications
>>> that can't easily be upgraded to 2.x due to testing, configuration, and
>>> implementation issues.
>>> 
>>> The current Logging PMC is focused on log4j 2.x only, and they have no
>>> desire to release 1.x
>>> 
 active development but focus only on CVE fixes
>>> 
>>> I would say, the primary goal of resurrecting 1.x is to focus on CVEs,
>> and
>>> keep the project buildable and testable.
>>> However, it might be the case, that certain fixes or features would
>> appear.
>>> 
>>> The sad story is that the industry is using 1.x A LOT, and what Logging
>> PMC
>>> did was
>>> they ignored the community, and they just stopped maintaining 1.x and
>>> focused on an incompatible 2.x
>>> 
>>> Not only do they stop maintaining 1.x, but they also deny others to pick
>> up
>>> the maintenance task.
>>> 
>>> What I am trying to do now is to pick up that maintenance activity.
>>> 
>>> Vladimir
>>> 
>> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Looking for a champion: resurrect log4j 1.x

[Dave Fisher]

Sent from my iPhone

> On Dec 21, 2021, at 3:33 AM, Enrico Olivelli  wrote:
> 
> Vladimir,
> I totally support this proposal.
> 
> Which are actually the steps we need to cut a release of log4j 1.x ?
> - establish an Apache project ?
> - do the fix
> - cut a release
> 
> Can this be done inside another Apache Project who "adopts" the log4j
> sources if the Logging Project doesn't want to do it ?

Perhaps Apache Commons where log4j started?
> 
> Enrico
> 
> 
> Il giorno mar 21 dic 2021 alle ore 08:36 Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> ha scritto:
> 
>>> Just wondering, is it even fulfilling the criteria of incubation?
>> 
>> I believe, the world does not need "active development in log4j 1.x"
>> nowadays.
>> What everybody needs from log4j 1.x is to fix security issues, fix
>> outstanding issues (if any),
>> keep the project buildable (e.g. avoid using outdated build systems), etc.
>> 
>>> it doesn't seem that sustainability is proven.
>> 
>> The problem is log4j 1.x is like COBOL of logging. There are apps that are
>> just stuck with log4j 1.x.
>> The proof of sustainability is that lots of existing apps will never
>> upgrade to 2.x because 2.x is incompatible.
>> If the compatibility layer of 2.x would be improved to handle 99.999% of
>> apps,
>> then we could indeed move 1.x to the attic.
>> 
>> The Incubator Cookbook says:
>>> The ASF provides software for the public good,
>> 
>> As I described, log4j 2.x is not a direct replacement for log4j 1.x, and
>> there are **lots** of applications
>> that can't easily be upgraded to 2.x due to testing, configuration, and
>> implementation issues.
>> 
>> The current Logging PMC is focused on log4j 2.x only, and they have no
>> desire to release 1.x
>> 
>>> active development but focus only on CVE fixes
>> 
>> I would say, the primary goal of resurrecting 1.x is to focus on CVEs, and
>> keep the project buildable and testable.
>> However, it might be the case, that certain fixes or features would appear.
>> 
>> The sad story is that the industry is using 1.x A LOT, and what Logging PMC
>> did was
>> they ignored the community, and they just stopped maintaining 1.x and
>> focused on an incompatible 2.x
>> 
>> Not only do they stop maintaining 1.x, but they also deny others to pick up
>> the maintenance task.
>> 
>> What I am trying to do now is to pick up that maintenance activity.
>> 
>> Vladimir
>> 

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Looking for a champion: resurrect log4j 1.x

[Dave Fisher]

Hi,

Have you discussed the approach you outlined with the logging PMC? It seems to 
me the idea of a drop in jar that allows log4j 1 over log4j  2 is an ideal 
product for that PMC to support.

All the best,
Dave

Sent from my iPhone

> On Dec 21, 2021, at 8:22 PM, 张铎  wrote:
> 
> I'm the one who migrated HBase from log4j to log4j2, and still tries to
> migrate hadoop but still can not find a suitable upgrading path...
> 
> For me, I do not prefer we release a new log4j 1.x, it has been EOL for
> many years, we should encourage people to upgrade to a newer logging
> framework. FWIW, even if we make a new release for log4j, the projects
> which rely on log4j still need to upgrade and make a new release right?
> 
> So then, I stand with Andrew's point, why people post an email here to get
> a new release for log4j 1.x, is mainly because they can not easily migrate
> to log4j2. If the log4j to log4j2 bridge can work perfectly, then for most
> old projects, they can just add a log4j12 bridge in the dependencies to
> solve most problems. And then they could start to migrate to pure log4j2
> incrementally and finally remove the log4j12 bridge.
> 
> But in my experience, first, the log4j12 bridge is not perfect. For
> example, since hadoop is still on log4j 1.x, I need to add log4j12 bridge
> dependency if I want to run UTs based on hadoop mini cluster, and then I
> need to manually copy some code from log4j1 in order to make it work, this
> is an example
> 
> https://github.com/apache/hbase/blob/master/hbase-logging/src/test/java/org/apache/log4j/FileAppender.java
> 
> I know in the bridge you will create log4j2 appender instead when reading
> the configuration file of log4j1, but since the appenders in log4j1 lack of
> some abilities, it is common that lots of projects will implement their own
> appender, I think we should take care of these usages and make them migrate
> smoothly.
> 
> And then, while fully migrating to log4j2, there is another annoying
> problem, the
> 
> log4j.rootLogger=INFO,console
> 
> grammar is gone! It is used among almost all the projects I've seen, and we
> just drop the support for it!
> 
> In HBase, I have to do some magics in the start scripts to avoid breaking
> our users too much
> 
> https://github.com/apache/hbase/blob/314e924e960d0d5c0c5e8ec436c75aaa6190b4c1/bin/hbase#L829
> 
> I really hope we could do better on backward compatibility, so when people
> ask for something about log4j1, we could just tell them to add the bridge
> to log4j2. And then easily fully migrate to log4j2 without too much effort
> if they want to use more features of log4j2, instead of finally making
> people ask here on whether they could revive log4j1...
> 
> That's my real feeling while working on migrating from log4j1 to log4j2.
> Please correct me if I'm wrong. I'm also willing to help here on making the
> bridge works better and also making the migration easier.
> 
> Thanks.
> 
> 
> 
> 
> 
> Andrew Purtell  于2021年12月22日周三 05:55写道：
> 
>>> as for the v1 :: COBOL analogy, that’s not a bad comparison. Basically,
>> users who haven’t bothered to upgrade in 10 years will have to end up
>> paying astronomical costs for consultants who can still work on ancient
>> software effectively to help modify their systems.
>> 
>> I have to take some exception to this. If the log4j 2.x configuration files
>> were compatible _enough_ with 1.x then taking this position would be
>> understandable. However, because they are not compatible in the way that
>> users require -- and the backwards compatibility is still marked as
>> 'experimental', even -- it is not great to blame users "who haven't
>> bothered to upgrade in 10 years". Turning this around, why is backwards
>> compatibility still experimental after 10 years? I am involved with several
>> Apache projects where we would love to upgrade from log4j 1 to log4j 2, and
>> have been talking about it for _years_. However, we have not been able to
>> easily do so because we actually care about operational cross-version
>> compatibility for our users. On some of these projects we are still stuck
>> on log4j 1.
>> 
>> I also support continuing releasing for log4j 1.x, and would volunteer some
>> of my time to assist in the effort.
>> 
>> 
>> On Tue, Dec 21, 2021 at 12:34 PM Matt Sicker  wrote:
>> 
>>> Nobody in the Logging PMC is blocking a release here. What we don’t want
>>> is to falsely advertise that v1 is still under development. We already
>> have
>>> a huge increase in mailing list, PR, and other traffic ever since
>>> Log4Shell, and if we resurrect v1, then it’ll quickly become impossible
>> to
>>> keep up with all the activity given the size of the PMC. If any
>> non-trivial
>>> work is to be done in v1, we’d prefer to see more than one person working
>>> on that, especially if we want to add more PMC members to oversee v1 in
>> the
>>> first place.
>>> 
>>> And as for the v1 :: COBOL analogy, that’s not a bad comparison.
>>> Basically, users who haven’t 

Re: Looking for a champion: resurrect log4j 1.x

[Duo Zhang]

I'm the one who migrated HBase from log4j to log4j2, and still tries to
migrate hadoop but still can not find a suitable upgrading path...

For me, I do not prefer we release a new log4j 1.x, it has been EOL for
many years, we should encourage people to upgrade to a newer logging
framework. FWIW, even if we make a new release for log4j, the projects
which rely on log4j still need to upgrade and make a new release right?

So then, I stand with Andrew's point, why people post an email here to get
a new release for log4j 1.x, is mainly because they can not easily migrate
to log4j2. If the log4j to log4j2 bridge can work perfectly, then for most
old projects, they can just add a log4j12 bridge in the dependencies to
solve most problems. And then they could start to migrate to pure log4j2
incrementally and finally remove the log4j12 bridge.

But in my experience, first, the log4j12 bridge is not perfect. For
example, since hadoop is still on log4j 1.x, I need to add log4j12 bridge
dependency if I want to run UTs based on hadoop mini cluster, and then I
need to manually copy some code from log4j1 in order to make it work, this
is an example

https://github.com/apache/hbase/blob/master/hbase-logging/src/test/java/org/apache/log4j/FileAppender.java

I know in the bridge you will create log4j2 appender instead when reading
the configuration file of log4j1, but since the appenders in log4j1 lack of
some abilities, it is common that lots of projects will implement their own
appender, I think we should take care of these usages and make them migrate
smoothly.

And then, while fully migrating to log4j2, there is another annoying
problem, the

log4j.rootLogger=INFO,console

grammar is gone! It is used among almost all the projects I've seen, and we
just drop the support for it!

In HBase, I have to do some magics in the start scripts to avoid breaking
our users too much

https://github.com/apache/hbase/blob/314e924e960d0d5c0c5e8ec436c75aaa6190b4c1/bin/hbase#L829

I really hope we could do better on backward compatibility, so when people
ask for something about log4j1, we could just tell them to add the bridge
to log4j2. And then easily fully migrate to log4j2 without too much effort
if they want to use more features of log4j2, instead of finally making
people ask here on whether they could revive log4j1...

That's my real feeling while working on migrating from log4j1 to log4j2.
Please correct me if I'm wrong. I'm also willing to help here on making the
bridge works better and also making the migration easier.

Thanks.





Andrew Purtell  于2021年12月22日周三 05:55写道：

> > as for the v1 :: COBOL analogy, that’s not a bad comparison. Basically,
> users who haven’t bothered to upgrade in 10 years will have to end up
> paying astronomical costs for consultants who can still work on ancient
> software effectively to help modify their systems.
>
> I have to take some exception to this. If the log4j 2.x configuration files
> were compatible _enough_ with 1.x then taking this position would be
> understandable. However, because they are not compatible in the way that
> users require -- and the backwards compatibility is still marked as
> 'experimental', even -- it is not great to blame users "who haven't
> bothered to upgrade in 10 years". Turning this around, why is backwards
> compatibility still experimental after 10 years? I am involved with several
> Apache projects where we would love to upgrade from log4j 1 to log4j 2, and
> have been talking about it for _years_. However, we have not been able to
> easily do so because we actually care about operational cross-version
> compatibility for our users. On some of these projects we are still stuck
> on log4j 1.
>
> I also support continuing releasing for log4j 1.x, and would volunteer some
> of my time to assist in the effort.
>
>
> On Tue, Dec 21, 2021 at 12:34 PM Matt Sicker  wrote:
>
> > Nobody in the Logging PMC is blocking a release here. What we don’t want
> > is to falsely advertise that v1 is still under development. We already
> have
> > a huge increase in mailing list, PR, and other traffic ever since
> > Log4Shell, and if we resurrect v1, then it’ll quickly become impossible
> to
> > keep up with all the activity given the size of the PMC. If any
> non-trivial
> > work is to be done in v1, we’d prefer to see more than one person working
> > on that, especially if we want to add more PMC members to oversee v1 in
> the
> > first place.
> >
> > And as for the v1 :: COBOL analogy, that’s not a bad comparison.
> > Basically, users who haven’t bothered to upgrade in 10 years will have to
> > end up paying astronomical costs for consultants who can still work on
> > ancient software effectively to help modify their systems. Was Maven even
> > widely used back when v1 was popular? Or were people still using a mix of
> > make or Ant?
> > --
> > Matt Sicker
> >
> > > On Dec 21, 2021, at 07:13, Romain Manni-Bucau 
> > wrote:
> > >
> > > Le mar. 21 déc. 2021 à 12:33, Enrico 

Re: Looking for a champion: resurrect log4j 1.x

[Andrew Purtell]

> as for the v1 :: COBOL analogy, that’s not a bad comparison. Basically,
users who haven’t bothered to upgrade in 10 years will have to end up
paying astronomical costs for consultants who can still work on ancient
software effectively to help modify their systems.

I have to take some exception to this. If the log4j 2.x configuration files
were compatible _enough_ with 1.x then taking this position would be
understandable. However, because they are not compatible in the way that
users require -- and the backwards compatibility is still marked as
'experimental', even -- it is not great to blame users "who haven't
bothered to upgrade in 10 years". Turning this around, why is backwards
compatibility still experimental after 10 years? I am involved with several
Apache projects where we would love to upgrade from log4j 1 to log4j 2, and
have been talking about it for _years_. However, we have not been able to
easily do so because we actually care about operational cross-version
compatibility for our users. On some of these projects we are still stuck
on log4j 1.

I also support continuing releasing for log4j 1.x, and would volunteer some
of my time to assist in the effort.


On Tue, Dec 21, 2021 at 12:34 PM Matt Sicker  wrote:

> Nobody in the Logging PMC is blocking a release here. What we don’t want
> is to falsely advertise that v1 is still under development. We already have
> a huge increase in mailing list, PR, and other traffic ever since
> Log4Shell, and if we resurrect v1, then it’ll quickly become impossible to
> keep up with all the activity given the size of the PMC. If any non-trivial
> work is to be done in v1, we’d prefer to see more than one person working
> on that, especially if we want to add more PMC members to oversee v1 in the
> first place.
>
> And as for the v1 :: COBOL analogy, that’s not a bad comparison.
> Basically, users who haven’t bothered to upgrade in 10 years will have to
> end up paying astronomical costs for consultants who can still work on
> ancient software effectively to help modify their systems. Was Maven even
> widely used back when v1 was popular? Or were people still using a mix of
> make or Ant?
> --
> Matt Sicker
>
> > On Dec 21, 2021, at 07:13, Romain Manni-Bucau 
> wrote:
> >
> > Le mar. 21 déc. 2021 à 12:33, Enrico Olivelli  a
> > écrit :
> >
> >> Vladimir,
> >> I totally support this proposal.
> >>
> >> Which are actually the steps we need to cut a release of log4j 1.x ?
> >> - establish an Apache project ?
> >>
> >
> > 1. Send a patch to apply on
> > http://svn.apache.org/repos/asf/logging/log4j/trunk
> >
> >
> >> - do the fix
> >>
> >
> > 2. Get it applied
> >
> >
> >> - cut a release
> >>
> >> Can this be done inside another Apache Project who "adopts" the log4j
> >> sources if the Logging Project doesn't want to do it ?
> >>
> >
> > The PMC of log4j2 is logging project so it should be done there, if not
> the
> > project can be forked inside Apache but should change of package until we
> > get the perms to reuse the same one which means likely as much work as
> just
> > getting it done at logging project so hope it is not needed ;).
> >
> >
> >>
> >> Enrico
> >>
> >>
> >> Il giorno mar 21 dic 2021 alle ore 08:36 Vladimir Sitnikov <
> >> sitnikov.vladi...@gmail.com> ha scritto:
> >>
>  Just wondering, is it even fulfilling the criteria of incubation?
> >>>
> >>> I believe, the world does not need "active development in log4j 1.x"
> >>> nowadays.
> >>> What everybody needs from log4j 1.x is to fix security issues, fix
> >>> outstanding issues (if any),
> >>> keep the project buildable (e.g. avoid using outdated build systems),
> >> etc.
> >>>
>  it doesn't seem that sustainability is proven.
> >>>
> >>> The problem is log4j 1.x is like COBOL of logging. There are apps that
> >> are
> >>> just stuck with log4j 1.x.
> >>> The proof of sustainability is that lots of existing apps will never
> >>> upgrade to 2.x because 2.x is incompatible.
> >>> If the compatibility layer of 2.x would be improved to handle 99.999%
> of
> >>> apps,
> >>> then we could indeed move 1.x to the attic.
> >>>
> >>> The Incubator Cookbook says:
>  The ASF provides software for the public good,
> >>>
> >>> As I described, log4j 2.x is not a direct replacement for log4j 1.x,
> and
> >>> there are **lots** of applications
> >>> that can't easily be upgraded to 2.x due to testing, configuration, and
> >>> implementation issues.
> >>>
> >>> The current Logging PMC is focused on log4j 2.x only, and they have no
> >>> desire to release 1.x
> >>>
>  active development but focus only on CVE fixes
> >>>
> >>> I would say, the primary goal of resurrecting 1.x is to focus on CVEs,
> >> and
> >>> keep the project buildable and testable.
> >>> However, it might be the case, that certain fixes or features would
> >> appear.
> >>>
> >>> The sad story is that the industry is using 1.x A LOT, and what Logging
> >> PMC
> >>> did was
> >>> they ignored the community, and they just stopped 

Re: Looking for a champion: resurrect log4j 1.x

[Matt Sicker]

Nobody in the Logging PMC is blocking a release here. What we don’t want is to 
falsely advertise that v1 is still under development. We already have a huge 
increase in mailing list, PR, and other traffic ever since Log4Shell, and if we 
resurrect v1, then it’ll quickly become impossible to keep up with all the 
activity given the size of the PMC. If any non-trivial work is to be done in 
v1, we’d prefer to see more than one person working on that, especially if we 
want to add more PMC members to oversee v1 in the first place.

And as for the v1 :: COBOL analogy, that’s not a bad comparison. Basically, 
users who haven’t bothered to upgrade in 10 years will have to end up paying 
astronomical costs for consultants who can still work on ancient software 
effectively to help modify their systems. Was Maven even widely used back when 
v1 was popular? Or were people still using a mix of make or Ant?
--
Matt Sicker

> On Dec 21, 2021, at 07:13, Romain Manni-Bucau  wrote:
> 
> Le mar. 21 déc. 2021 à 12:33, Enrico Olivelli  a
> écrit :
> 
>> Vladimir,
>> I totally support this proposal.
>> 
>> Which are actually the steps we need to cut a release of log4j 1.x ?
>> - establish an Apache project ?
>> 
> 
> 1. Send a patch to apply on
> http://svn.apache.org/repos/asf/logging/log4j/trunk
> 
> 
>> - do the fix
>> 
> 
> 2. Get it applied
> 
> 
>> - cut a release
>> 
>> Can this be done inside another Apache Project who "adopts" the log4j
>> sources if the Logging Project doesn't want to do it ?
>> 
> 
> The PMC of log4j2 is logging project so it should be done there, if not the
> project can be forked inside Apache but should change of package until we
> get the perms to reuse the same one which means likely as much work as just
> getting it done at logging project so hope it is not needed ;).
> 
> 
>> 
>> Enrico
>> 
>> 
>> Il giorno mar 21 dic 2021 alle ore 08:36 Vladimir Sitnikov <
>> sitnikov.vladi...@gmail.com> ha scritto:
>> 
 Just wondering, is it even fulfilling the criteria of incubation?
>>> 
>>> I believe, the world does not need "active development in log4j 1.x"
>>> nowadays.
>>> What everybody needs from log4j 1.x is to fix security issues, fix
>>> outstanding issues (if any),
>>> keep the project buildable (e.g. avoid using outdated build systems),
>> etc.
>>> 
 it doesn't seem that sustainability is proven.
>>> 
>>> The problem is log4j 1.x is like COBOL of logging. There are apps that
>> are
>>> just stuck with log4j 1.x.
>>> The proof of sustainability is that lots of existing apps will never
>>> upgrade to 2.x because 2.x is incompatible.
>>> If the compatibility layer of 2.x would be improved to handle 99.999% of
>>> apps,
>>> then we could indeed move 1.x to the attic.
>>> 
>>> The Incubator Cookbook says:
 The ASF provides software for the public good,
>>> 
>>> As I described, log4j 2.x is not a direct replacement for log4j 1.x, and
>>> there are **lots** of applications
>>> that can't easily be upgraded to 2.x due to testing, configuration, and
>>> implementation issues.
>>> 
>>> The current Logging PMC is focused on log4j 2.x only, and they have no
>>> desire to release 1.x
>>> 
 active development but focus only on CVE fixes
>>> 
>>> I would say, the primary goal of resurrecting 1.x is to focus on CVEs,
>> and
>>> keep the project buildable and testable.
>>> However, it might be the case, that certain fixes or features would
>> appear.
>>> 
>>> The sad story is that the industry is using 1.x A LOT, and what Logging
>> PMC
>>> did was
>>> they ignored the community, and they just stopped maintaining 1.x and
>>> focused on an incompatible 2.x
>>> 
>>> Not only do they stop maintaining 1.x, but they also deny others to pick
>> up
>>> the maintenance task.
>>> 
>>> What I am trying to do now is to pick up that maintenance activity.
>>> 
>>> Vladimir
>>> 
>> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Looking for a champion: resurrect log4j 1.x

[Romain Manni-Bucau]

Le mar. 21 déc. 2021 à 12:33, Enrico Olivelli  a
écrit :

> Vladimir,
> I totally support this proposal.
>
> Which are actually the steps we need to cut a release of log4j 1.x ?
> - establish an Apache project ?
>

1. Send a patch to apply on
http://svn.apache.org/repos/asf/logging/log4j/trunk


> - do the fix
>

2. Get it applied


> - cut a release
>
> Can this be done inside another Apache Project who "adopts" the log4j
> sources if the Logging Project doesn't want to do it ?
>

The PMC of log4j2 is logging project so it should be done there, if not the
project can be forked inside Apache but should change of package until we
get the perms to reuse the same one which means likely as much work as just
getting it done at logging project so hope it is not needed ;).


>
> Enrico
>
>
> Il giorno mar 21 dic 2021 alle ore 08:36 Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> ha scritto:
>
> > >Just wondering, is it even fulfilling the criteria of incubation?
> >
> > I believe, the world does not need "active development in log4j 1.x"
> > nowadays.
> > What everybody needs from log4j 1.x is to fix security issues, fix
> > outstanding issues (if any),
> > keep the project buildable (e.g. avoid using outdated build systems),
> etc.
> >
> > >it doesn't seem that sustainability is proven.
> >
> > The problem is log4j 1.x is like COBOL of logging. There are apps that
> are
> > just stuck with log4j 1.x.
> > The proof of sustainability is that lots of existing apps will never
> > upgrade to 2.x because 2.x is incompatible.
> > If the compatibility layer of 2.x would be improved to handle 99.999% of
> > apps,
> > then we could indeed move 1.x to the attic.
> >
> > The Incubator Cookbook says:
> > >The ASF provides software for the public good,
> >
> > As I described, log4j 2.x is not a direct replacement for log4j 1.x, and
> > there are **lots** of applications
> > that can't easily be upgraded to 2.x due to testing, configuration, and
> > implementation issues.
> >
> > The current Logging PMC is focused on log4j 2.x only, and they have no
> > desire to release 1.x
> >
> > >active development but focus only on CVE fixes
> >
> > I would say, the primary goal of resurrecting 1.x is to focus on CVEs,
> and
> > keep the project buildable and testable.
> > However, it might be the case, that certain fixes or features would
> appear.
> >
> > The sad story is that the industry is using 1.x A LOT, and what Logging
> PMC
> > did was
> > they ignored the community, and they just stopped maintaining 1.x and
> > focused on an incompatible 2.x
> >
> > Not only do they stop maintaining 1.x, but they also deny others to pick
> up
> > the maintenance task.
> >
> > What I am trying to do now is to pick up that maintenance activity.
> >
> > Vladimir
> >
>

Re: Looking for a champion: resurrect log4j 1.x

[Enrico Olivelli]

Vladimir,
I totally support this proposal.

Which are actually the steps we need to cut a release of log4j 1.x ?
- establish an Apache project ?
- do the fix
- cut a release

Can this be done inside another Apache Project who "adopts" the log4j
sources if the Logging Project doesn't want to do it ?

Enrico


Il giorno mar 21 dic 2021 alle ore 08:36 Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> ha scritto:

> >Just wondering, is it even fulfilling the criteria of incubation?
>
> I believe, the world does not need "active development in log4j 1.x"
> nowadays.
> What everybody needs from log4j 1.x is to fix security issues, fix
> outstanding issues (if any),
> keep the project buildable (e.g. avoid using outdated build systems), etc.
>
> >it doesn't seem that sustainability is proven.
>
> The problem is log4j 1.x is like COBOL of logging. There are apps that are
> just stuck with log4j 1.x.
> The proof of sustainability is that lots of existing apps will never
> upgrade to 2.x because 2.x is incompatible.
> If the compatibility layer of 2.x would be improved to handle 99.999% of
> apps,
> then we could indeed move 1.x to the attic.
>
> The Incubator Cookbook says:
> >The ASF provides software for the public good,
>
> As I described, log4j 2.x is not a direct replacement for log4j 1.x, and
> there are **lots** of applications
> that can't easily be upgraded to 2.x due to testing, configuration, and
> implementation issues.
>
> The current Logging PMC is focused on log4j 2.x only, and they have no
> desire to release 1.x
>
> >active development but focus only on CVE fixes
>
> I would say, the primary goal of resurrecting 1.x is to focus on CVEs, and
> keep the project buildable and testable.
> However, it might be the case, that certain fixes or features would appear.
>
> The sad story is that the industry is using 1.x A LOT, and what Logging PMC
> did was
> they ignored the community, and they just stopped maintaining 1.x and
> focused on an incompatible 2.x
>
> Not only do they stop maintaining 1.x, but they also deny others to pick up
> the maintenance task.
>
> What I am trying to do now is to pick up that maintenance activity.
>
> Vladimir
>

Re: Looking for a champion: resurrect log4j 1.x

[Vladimir Sitnikov]

>Just wondering, is it even fulfilling the criteria of incubation?

I believe, the world does not need "active development in log4j 1.x"
nowadays.
What everybody needs from log4j 1.x is to fix security issues, fix
outstanding issues (if any),
keep the project buildable (e.g. avoid using outdated build systems), etc.

>it doesn't seem that sustainability is proven.

The problem is log4j 1.x is like COBOL of logging. There are apps that are
just stuck with log4j 1.x.
The proof of sustainability is that lots of existing apps will never
upgrade to 2.x because 2.x is incompatible.
If the compatibility layer of 2.x would be improved to handle 99.999% of
apps,
then we could indeed move 1.x to the attic.

The Incubator Cookbook says:
>The ASF provides software for the public good,

As I described, log4j 2.x is not a direct replacement for log4j 1.x, and
there are **lots** of applications
that can't easily be upgraded to 2.x due to testing, configuration, and
implementation issues.

The current Logging PMC is focused on log4j 2.x only, and they have no
desire to release 1.x

>active development but focus only on CVE fixes

I would say, the primary goal of resurrecting 1.x is to focus on CVEs, and
keep the project buildable and testable.
However, it might be the case, that certain fixes or features would appear.

The sad story is that the industry is using 1.x A LOT, and what Logging PMC
did was
they ignored the community, and they just stopped maintaining 1.x and
focused on an incompatible 2.x

Not only do they stop maintaining 1.x, but they also deny others to pick up
the maintenance task.

What I am trying to do now is to pick up that maintenance activity.

Vladimir

Re: Looking for a champion: resurrect log4j 1.x

[Felix Cheung]

What are the concerning security vulnerabilities in log4j 1 and the
severity level?

I saw one mentioned in the thread which apparently redhat had fixed (with
socket stream deserialization)


On Mon, Dec 20, 2021 at 3:56 PM Martin Gainty  wrote:

> i would ping the original author ceki gulcu
> Random thoughts by Ceki Gülcü: The forces and vulnerabilities of the
> Apache model<
> https://ceki.blogspot.com/2010/05/forces-and-vulnerabilites-of-apache.html
> >
> Random thoughts by Ceki Gülcü: The forces and vulnerabilities of the
> Apache model<
> https://ceki.blogspot.com/2010/05/forces-and-vulnerabilites-of-apache.html
> >
> Brett Porter said I agree with Bertrand's point. Also, it is necessary
> to be careful not to ascribe too much power to the votes themselves - they
> are only a tool for gauging consensus, which is the main objective.
> ceki.blogspot.com
>
> Best Regards,
> martin-
>
> 
> From: Jungtaek Lim 
> Sent: Monday, December 20, 2021 4:26 PM
> To: general@incubator.apache.org 
> Subject: Re: Looking for a champion: resurrect log4j 1.x
>
> Just wondering, is it even fulfilling the criteria of incubation? Have
> there been any similar cases before?
>
> It was stated that there will be no effort on active development but focus
> only on CVE fixes. This sounds to me as the project will start as only
> fixing a few known CVEs and stop till other CVEs are discovered (there may
> be huge difference between proactively discovering CVEs vs passively fixing
> the reported CVEs by others), and never be attempted to become TLP.
> Majority of status reports will be blank. That said, it doesn't seem that
> sustainability is proven.
>
>
> On Mon, Dec 20, 2021 at 10:51 PM John D. Ament 
> wrote:
>
> > On Mon, Dec 20, 2021 at 8:42 AM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > Guess there are 4 options:
> > >
> > > 1. resurrect log4j1 and let it die again
> > > 2. do a log4j1 release for the CVE under logging umbrella (as a
> > subproject)
> > > - after all log4j1 belongs to logging as a subproject already (
> > > https://logging.apache.org/dormant.html)
> > > 3. the log4j1-log4j2 bridge (but agree this is not a solution and
> > requires
> > > to do 2 to be useful technically since none of log4j1 users will want
> to
> > > import log4j2, at least cause it is not compatible with java version or
> > due
> > > to the injected bytecode like module-info)
> > > 4. do a CVE fix release fork on github or any other hosting
> > >
> > > Personally I don't think 1 or 3 are real options, 4 is but not that
> nice
> > > indeed (due to the fact it would be yet another forks but also cause it
> > > requires some GAV change or build hack to be done properly) so from my
> > > window I would be tempted to push for 2 which sounds like a quick win
> for
> > > everyone.
> > >
> >
> > Questions like this probably should be on one of the logging lists rather
> > than the incubator list.  The Incubator would not create a hostile fork
> > under any circumstance, including of an existing project/sub-project
> within
> > Apache.  In a situation like this it would be purely a call by the
> Logging
> > PMC, whether or not they want the Incubator to create the podling.
> >
> >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le lun. 20 déc. 2021 à 14:32, John D. Ament  a
> > > écrit :
> > >
> > > > Hi Vladimir,
> > > >
> > > > I think based on what you're describing and the Logging PMC's
> response,
> > > > re-incubating the project makes sense.  I would be curious if the
> > Logging
> > > > PMC would be interested in restarting the sub-project after a
> > successful
> > > > incubation period.  This seems to match what Ralph is suggesting as
> > well.
> > > >
> > > > Typically this would mean that the VP Logging PMC would serve as the
> > > > champion, and as the sponsor the Logging PMC would still be the one
&g

Re: Looking for a champion: resurrect log4j 1.x

[Martin Gainty]

i would ping the original author ceki gulcu
Random thoughts by Ceki Gülcü: The forces and vulnerabilities of the Apache 
model<https://ceki.blogspot.com/2010/05/forces-and-vulnerabilites-of-apache.html>
Random thoughts by Ceki Gülcü: The forces and vulnerabilities of the Apache 
model<https://ceki.blogspot.com/2010/05/forces-and-vulnerabilites-of-apache.html>
Brett Porter said I agree with Bertrand's point. Also, it is necessary to 
be careful not to ascribe too much power to the votes themselves - they are 
only a tool for gauging consensus, which is the main objective.
ceki.blogspot.com

Best Regards,
martin-


From: Jungtaek Lim 
Sent: Monday, December 20, 2021 4:26 PM
To: general@incubator.apache.org 
Subject: Re: Looking for a champion: resurrect log4j 1.x

Just wondering, is it even fulfilling the criteria of incubation? Have
there been any similar cases before?

It was stated that there will be no effort on active development but focus
only on CVE fixes. This sounds to me as the project will start as only
fixing a few known CVEs and stop till other CVEs are discovered (there may
be huge difference between proactively discovering CVEs vs passively fixing
the reported CVEs by others), and never be attempted to become TLP.
Majority of status reports will be blank. That said, it doesn't seem that
sustainability is proven.


On Mon, Dec 20, 2021 at 10:51 PM John D. Ament 
wrote:

> On Mon, Dec 20, 2021 at 8:42 AM Romain Manni-Bucau 
> wrote:
>
> > Guess there are 4 options:
> >
> > 1. resurrect log4j1 and let it die again
> > 2. do a log4j1 release for the CVE under logging umbrella (as a
> subproject)
> > - after all log4j1 belongs to logging as a subproject already (
> > https://logging.apache.org/dormant.html)
> > 3. the log4j1-log4j2 bridge (but agree this is not a solution and
> requires
> > to do 2 to be useful technically since none of log4j1 users will want to
> > import log4j2, at least cause it is not compatible with java version or
> due
> > to the injected bytecode like module-info)
> > 4. do a CVE fix release fork on github or any other hosting
> >
> > Personally I don't think 1 or 3 are real options, 4 is but not that nice
> > indeed (due to the fact it would be yet another forks but also cause it
> > requires some GAV change or build hack to be done properly) so from my
> > window I would be tempted to push for 2 which sounds like a quick win for
> > everyone.
> >
>
> Questions like this probably should be on one of the logging lists rather
> than the incubator list.  The Incubator would not create a hostile fork
> under any circumstance, including of an existing project/sub-project within
> Apache.  In a situation like this it would be purely a call by the Logging
> PMC, whether or not they want the Incubator to create the podling.
>
>
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le lun. 20 déc. 2021 à 14:32, John D. Ament  a
> > écrit :
> >
> > > Hi Vladimir,
> > >
> > > I think based on what you're describing and the Logging PMC's response,
> > > re-incubating the project makes sense.  I would be curious if the
> Logging
> > > PMC would be interested in restarting the sub-project after a
> successful
> > > incubation period.  This seems to match what Ralph is suggesting as
> well.
> > >
> > > Typically this would mean that the VP Logging PMC would serve as the
> > > champion, and as the sponsor the Logging PMC would still be the one to
> > vote
> > > to add the project to the incubator.  If the VP Logging isn't
> interested
> > in
> > > doing this, I would recommend starting out the project as a standalone
> > > podling and keeping the Incubator as sponsor rather than Logging.  See
> > [1]
> > > for some details on those notes.  The incubator would be responsible
> for
> > > voting on releases, receiving notices for new PPMC members, etc
> > regardless
> > > of who is the sponsor.  Given enough contributors and a diverse
> > contributor
> > > base then the Incubator PMC and the Logging PMC (if they're the
> sponsor)
> > > would vote whether everyone feels the new project can be brought back
> to
> > > the Logging p

Re: Looking for a champion: resurrect log4j 1.x

[Jungtaek Lim]

Just wondering, is it even fulfilling the criteria of incubation? Have
there been any similar cases before?

It was stated that there will be no effort on active development but focus
only on CVE fixes. This sounds to me as the project will start as only
fixing a few known CVEs and stop till other CVEs are discovered (there may
be huge difference between proactively discovering CVEs vs passively fixing
the reported CVEs by others), and never be attempted to become TLP.
Majority of status reports will be blank. That said, it doesn't seem that
sustainability is proven.


On Mon, Dec 20, 2021 at 10:51 PM John D. Ament 
wrote:

> On Mon, Dec 20, 2021 at 8:42 AM Romain Manni-Bucau 
> wrote:
>
> > Guess there are 4 options:
> >
> > 1. resurrect log4j1 and let it die again
> > 2. do a log4j1 release for the CVE under logging umbrella (as a
> subproject)
> > - after all log4j1 belongs to logging as a subproject already (
> > https://logging.apache.org/dormant.html)
> > 3. the log4j1-log4j2 bridge (but agree this is not a solution and
> requires
> > to do 2 to be useful technically since none of log4j1 users will want to
> > import log4j2, at least cause it is not compatible with java version or
> due
> > to the injected bytecode like module-info)
> > 4. do a CVE fix release fork on github or any other hosting
> >
> > Personally I don't think 1 or 3 are real options, 4 is but not that nice
> > indeed (due to the fact it would be yet another forks but also cause it
> > requires some GAV change or build hack to be done properly) so from my
> > window I would be tempted to push for 2 which sounds like a quick win for
> > everyone.
> >
>
> Questions like this probably should be on one of the logging lists rather
> than the incubator list.  The Incubator would not create a hostile fork
> under any circumstance, including of an existing project/sub-project within
> Apache.  In a situation like this it would be purely a call by the Logging
> PMC, whether or not they want the Incubator to create the podling.
>
>
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le lun. 20 déc. 2021 à 14:32, John D. Ament  a
> > écrit :
> >
> > > Hi Vladimir,
> > >
> > > I think based on what you're describing and the Logging PMC's response,
> > > re-incubating the project makes sense.  I would be curious if the
> Logging
> > > PMC would be interested in restarting the sub-project after a
> successful
> > > incubation period.  This seems to match what Ralph is suggesting as
> well.
> > >
> > > Typically this would mean that the VP Logging PMC would serve as the
> > > champion, and as the sponsor the Logging PMC would still be the one to
> > vote
> > > to add the project to the incubator.  If the VP Logging isn't
> interested
> > in
> > > doing this, I would recommend starting out the project as a standalone
> > > podling and keeping the Incubator as sponsor rather than Logging.  See
> > [1]
> > > for some details on those notes.  The incubator would be responsible
> for
> > > voting on releases, receiving notices for new PPMC members, etc
> > regardless
> > > of who is the sponsor.  Given enough contributors and a diverse
> > contributor
> > > base then the Incubator PMC and the Logging PMC (if they're the
> sponsor)
> > > would vote whether everyone feels the new project can be brought back
> to
> > > the Logging project.  We can also decide as it gets closer to
> graduation
> > to
> > > move the podling into a sub-project if that's what everyone agrees.
> > >
> > > I would be up for helping you get through the incubator.  If VP Logging
> > > doesn't want to own the sponsorship part, I can be your Champion.
> > >
> > > John
> > >
> > >
> > > [1]: https://incubator.apache.org/guides/proposal.html#background
> > >
> > > On Mon, Dec 20, 2021 at 8:20 AM Vladimir Sitnikov <
> > > sitnikov.vladi...@gmail.com> wrote:
> > >
> > > > >Do you have "facts" (like message on mailing list) ?
> > > >
> > > > I am not sure what you mean.
> > > >
> > > > For example:
> > > >
> > > > 1) Ralph Goers says the existing committers did not touch 1.x code a
> > lot:
> > > > https://lists.apache.org/thread/j6zrdp1d148qpkg0g7x3cc41o070oq6n
> > > > Ralph>Virtually all of the contributors to the Log4j 1.x project
> left a
> > > few
> > > > years before it was declared
> > > > Ralph>EOL. That is the primary reason it was retired. Although the
> > > current
> > > > set of committers have
> > > > Ralph>access to the code, none of us have ever built it
> > > >
> > > > 2) Ralph Goers (a member of Logging PMC) suggested that one of the
> ways
> > > to
> > > > move forward is to re-incubate log4j 1.x:
> > > > 

Re: Looking for a champion: resurrect log4j 1.x

[John D. Ament]

On Mon, Dec 20, 2021 at 8:42 AM Romain Manni-Bucau 
wrote:

> Guess there are 4 options:
>
> 1. resurrect log4j1 and let it die again
> 2. do a log4j1 release for the CVE under logging umbrella (as a subproject)
> - after all log4j1 belongs to logging as a subproject already (
> https://logging.apache.org/dormant.html)
> 3. the log4j1-log4j2 bridge (but agree this is not a solution and requires
> to do 2 to be useful technically since none of log4j1 users will want to
> import log4j2, at least cause it is not compatible with java version or due
> to the injected bytecode like module-info)
> 4. do a CVE fix release fork on github or any other hosting
>
> Personally I don't think 1 or 3 are real options, 4 is but not that nice
> indeed (due to the fact it would be yet another forks but also cause it
> requires some GAV change or build hack to be done properly) so from my
> window I would be tempted to push for 2 which sounds like a quick win for
> everyone.
>

Questions like this probably should be on one of the logging lists rather
than the incubator list.  The Incubator would not create a hostile fork
under any circumstance, including of an existing project/sub-project within
Apache.  In a situation like this it would be purely a call by the Logging
PMC, whether or not they want the Incubator to create the podling.


>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le lun. 20 déc. 2021 à 14:32, John D. Ament  a
> écrit :
>
> > Hi Vladimir,
> >
> > I think based on what you're describing and the Logging PMC's response,
> > re-incubating the project makes sense.  I would be curious if the Logging
> > PMC would be interested in restarting the sub-project after a successful
> > incubation period.  This seems to match what Ralph is suggesting as well.
> >
> > Typically this would mean that the VP Logging PMC would serve as the
> > champion, and as the sponsor the Logging PMC would still be the one to
> vote
> > to add the project to the incubator.  If the VP Logging isn't interested
> in
> > doing this, I would recommend starting out the project as a standalone
> > podling and keeping the Incubator as sponsor rather than Logging.  See
> [1]
> > for some details on those notes.  The incubator would be responsible for
> > voting on releases, receiving notices for new PPMC members, etc
> regardless
> > of who is the sponsor.  Given enough contributors and a diverse
> contributor
> > base then the Incubator PMC and the Logging PMC (if they're the sponsor)
> > would vote whether everyone feels the new project can be brought back to
> > the Logging project.  We can also decide as it gets closer to graduation
> to
> > move the podling into a sub-project if that's what everyone agrees.
> >
> > I would be up for helping you get through the incubator.  If VP Logging
> > doesn't want to own the sponsorship part, I can be your Champion.
> >
> > John
> >
> >
> > [1]: https://incubator.apache.org/guides/proposal.html#background
> >
> > On Mon, Dec 20, 2021 at 8:20 AM Vladimir Sitnikov <
> > sitnikov.vladi...@gmail.com> wrote:
> >
> > > >Do you have "facts" (like message on mailing list) ?
> > >
> > > I am not sure what you mean.
> > >
> > > For example:
> > >
> > > 1) Ralph Goers says the existing committers did not touch 1.x code a
> lot:
> > > https://lists.apache.org/thread/j6zrdp1d148qpkg0g7x3cc41o070oq6n
> > > Ralph>Virtually all of the contributors to the Log4j 1.x project left a
> > few
> > > years before it was declared
> > > Ralph>EOL. That is the primary reason it was retired. Although the
> > current
> > > set of committers have
> > > Ralph>access to the code, none of us have ever built it
> > >
> > > 2) Ralph Goers (a member of Logging PMC) suggested that one of the ways
> > to
> > > move forward is to re-incubate log4j 1.x:
> > > https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5
> > >
> > > This in conjunction with #1 sounds like the current logging PMC is not
> > > interested in moving log4j 1.x forward.
> > >
> > > 3) I suggest moving log4j 1.x to Git, and nobody from PMC approves the
> > > change;
> > > Gary Gregory (a member of Logging PMC) votes with -1 (binding):
> > > https://lists.apache.org/thread/y89v84okzs76g2yl760vx5yc0w1y4yd8
> > >
> > > 4) Both Gary and Mike push for "improving log4j 1->2 compatibility
> > layer":
> > > https://lists.apache.org/thread/hq2m11f1w9yp031r5f65b9h4ym2zy1kc
> > > https://lists.apache.org/thread/tw172svxt1q6wds7lt9szyjw2sxjf34n
> > >
> > > I understand that log4j2 team might want everybody to upgrade to 2.x,
> > > however, that is not possible since the apps would need significant
> > > regression testing,
> > > the compatibility layer is far from 

Re: Looking for a champion: resurrect log4j 1.x

[Romain Manni-Bucau]

Guess there are 4 options:

1. resurrect log4j1 and let it die again
2. do a log4j1 release for the CVE under logging umbrella (as a subproject)
- after all log4j1 belongs to logging as a subproject already (
https://logging.apache.org/dormant.html)
3. the log4j1-log4j2 bridge (but agree this is not a solution and requires
to do 2 to be useful technically since none of log4j1 users will want to
import log4j2, at least cause it is not compatible with java version or due
to the injected bytecode like module-info)
4. do a CVE fix release fork on github or any other hosting

Personally I don't think 1 or 3 are real options, 4 is but not that nice
indeed (due to the fact it would be yet another forks but also cause it
requires some GAV change or build hack to be done properly) so from my
window I would be tempted to push for 2 which sounds like a quick win for
everyone.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 20 déc. 2021 à 14:32, John D. Ament  a
écrit :

> Hi Vladimir,
>
> I think based on what you're describing and the Logging PMC's response,
> re-incubating the project makes sense.  I would be curious if the Logging
> PMC would be interested in restarting the sub-project after a successful
> incubation period.  This seems to match what Ralph is suggesting as well.
>
> Typically this would mean that the VP Logging PMC would serve as the
> champion, and as the sponsor the Logging PMC would still be the one to vote
> to add the project to the incubator.  If the VP Logging isn't interested in
> doing this, I would recommend starting out the project as a standalone
> podling and keeping the Incubator as sponsor rather than Logging.  See [1]
> for some details on those notes.  The incubator would be responsible for
> voting on releases, receiving notices for new PPMC members, etc regardless
> of who is the sponsor.  Given enough contributors and a diverse contributor
> base then the Incubator PMC and the Logging PMC (if they're the sponsor)
> would vote whether everyone feels the new project can be brought back to
> the Logging project.  We can also decide as it gets closer to graduation to
> move the podling into a sub-project if that's what everyone agrees.
>
> I would be up for helping you get through the incubator.  If VP Logging
> doesn't want to own the sponsorship part, I can be your Champion.
>
> John
>
>
> [1]: https://incubator.apache.org/guides/proposal.html#background
>
> On Mon, Dec 20, 2021 at 8:20 AM Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote:
>
> > >Do you have "facts" (like message on mailing list) ?
> >
> > I am not sure what you mean.
> >
> > For example:
> >
> > 1) Ralph Goers says the existing committers did not touch 1.x code a lot:
> > https://lists.apache.org/thread/j6zrdp1d148qpkg0g7x3cc41o070oq6n
> > Ralph>Virtually all of the contributors to the Log4j 1.x project left a
> few
> > years before it was declared
> > Ralph>EOL. That is the primary reason it was retired. Although the
> current
> > set of committers have
> > Ralph>access to the code, none of us have ever built it
> >
> > 2) Ralph Goers (a member of Logging PMC) suggested that one of the ways
> to
> > move forward is to re-incubate log4j 1.x:
> > https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5
> >
> > This in conjunction with #1 sounds like the current logging PMC is not
> > interested in moving log4j 1.x forward.
> >
> > 3) I suggest moving log4j 1.x to Git, and nobody from PMC approves the
> > change;
> > Gary Gregory (a member of Logging PMC) votes with -1 (binding):
> > https://lists.apache.org/thread/y89v84okzs76g2yl760vx5yc0w1y4yd8
> >
> > 4) Both Gary and Mike push for "improving log4j 1->2 compatibility
> layer":
> > https://lists.apache.org/thread/hq2m11f1w9yp031r5f65b9h4ym2zy1kc
> > https://lists.apache.org/thread/tw172svxt1q6wds7lt9szyjw2sxjf34n
> >
> > I understand that log4j2 team might want everybody to upgrade to 2.x,
> > however, that is not possible since the apps would need significant
> > regression testing,
> > the compatibility layer is far from perfect, and so on.
> > Many apps are fine with 1.x, and they do not need 2.x features.
> > There's no reason to upgrade, so I am not interested in investing time in
> > improving
> > the compatibility layer.
> >
> > Is it what you ask?
> >
> > Vladimir
> >
>

Re: Looking for a champion: resurrect log4j 1.x

[John D. Ament]

Hi Vladimir,

I think based on what you're describing and the Logging PMC's response,
re-incubating the project makes sense.  I would be curious if the Logging
PMC would be interested in restarting the sub-project after a successful
incubation period.  This seems to match what Ralph is suggesting as well.

Typically this would mean that the VP Logging PMC would serve as the
champion, and as the sponsor the Logging PMC would still be the one to vote
to add the project to the incubator.  If the VP Logging isn't interested in
doing this, I would recommend starting out the project as a standalone
podling and keeping the Incubator as sponsor rather than Logging.  See [1]
for some details on those notes.  The incubator would be responsible for
voting on releases, receiving notices for new PPMC members, etc regardless
of who is the sponsor.  Given enough contributors and a diverse contributor
base then the Incubator PMC and the Logging PMC (if they're the sponsor)
would vote whether everyone feels the new project can be brought back to
the Logging project.  We can also decide as it gets closer to graduation to
move the podling into a sub-project if that's what everyone agrees.

I would be up for helping you get through the incubator.  If VP Logging
doesn't want to own the sponsorship part, I can be your Champion.

John


[1]: https://incubator.apache.org/guides/proposal.html#background

On Mon, Dec 20, 2021 at 8:20 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> >Do you have "facts" (like message on mailing list) ?
>
> I am not sure what you mean.
>
> For example:
>
> 1) Ralph Goers says the existing committers did not touch 1.x code a lot:
> https://lists.apache.org/thread/j6zrdp1d148qpkg0g7x3cc41o070oq6n
> Ralph>Virtually all of the contributors to the Log4j 1.x project left a few
> years before it was declared
> Ralph>EOL. That is the primary reason it was retired. Although the current
> set of committers have
> Ralph>access to the code, none of us have ever built it
>
> 2) Ralph Goers (a member of Logging PMC) suggested that one of the ways to
> move forward is to re-incubate log4j 1.x:
> https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5
>
> This in conjunction with #1 sounds like the current logging PMC is not
> interested in moving log4j 1.x forward.
>
> 3) I suggest moving log4j 1.x to Git, and nobody from PMC approves the
> change;
> Gary Gregory (a member of Logging PMC) votes with -1 (binding):
> https://lists.apache.org/thread/y89v84okzs76g2yl760vx5yc0w1y4yd8
>
> 4) Both Gary and Mike push for "improving log4j 1->2 compatibility layer":
> https://lists.apache.org/thread/hq2m11f1w9yp031r5f65b9h4ym2zy1kc
> https://lists.apache.org/thread/tw172svxt1q6wds7lt9szyjw2sxjf34n
>
> I understand that log4j2 team might want everybody to upgrade to 2.x,
> however, that is not possible since the apps would need significant
> regression testing,
> the compatibility layer is far from perfect, and so on.
> Many apps are fine with 1.x, and they do not need 2.x features.
> There's no reason to upgrade, so I am not interested in investing time in
> improving
> the compatibility layer.
>
> Is it what you ask?
>
> Vladimir
>

Re: Looking for a champion: resurrect log4j 1.x

[Vladimir Sitnikov]

>Do you have "facts" (like message on mailing list) ?

I am not sure what you mean.

For example:

1) Ralph Goers says the existing committers did not touch 1.x code a lot:
https://lists.apache.org/thread/j6zrdp1d148qpkg0g7x3cc41o070oq6n
Ralph>Virtually all of the contributors to the Log4j 1.x project left a few
years before it was declared
Ralph>EOL. That is the primary reason it was retired. Although the current
set of committers have
Ralph>access to the code, none of us have ever built it

2) Ralph Goers (a member of Logging PMC) suggested that one of the ways to
move forward is to re-incubate log4j 1.x:
https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5

This in conjunction with #1 sounds like the current logging PMC is not
interested in moving log4j 1.x forward.

3) I suggest moving log4j 1.x to Git, and nobody from PMC approves the
change;
Gary Gregory (a member of Logging PMC) votes with -1 (binding):
https://lists.apache.org/thread/y89v84okzs76g2yl760vx5yc0w1y4yd8

4) Both Gary and Mike push for "improving log4j 1->2 compatibility layer":
https://lists.apache.org/thread/hq2m11f1w9yp031r5f65b9h4ym2zy1kc
https://lists.apache.org/thread/tw172svxt1q6wds7lt9szyjw2sxjf34n

I understand that log4j2 team might want everybody to upgrade to 2.x,
however, that is not possible since the apps would need significant
regression testing,
the compatibility layer is far from perfect, and so on.
Many apps are fine with 1.x, and they do not need 2.x features.
There's no reason to upgrade, so I am not interested in investing time in
improving
the compatibility layer.

Is it what you ask?

Vladimir

Re: Looking for a champion: resurrect log4j 1.x

[Jean-Baptiste Onofré]

Hi Vladimir,

Thanks for the update. Do you have "facts" (like message on mailing list) ?
I think we can discuss with the log4j PMC members.
Depending of their feedback, we will find a way. My preference is to 
have log4j1 on Apache Logging umbrella.


Let's see what others think.

Regards
JB

On 20/12/2021 08:48, Vladimir Sitnikov wrote:

JB>Anyone can propose new releases on any branches (including old ones).
JB>If you need my support/help on this, please let me know.

I and the other contributors tried to suggest PRs, however, log4j pmc
actively denies them.
They suggest contributors should focus on polishing log4j 1->2
compatibility layer.
Making the compatibility 100% correct is hard, so I believe forcing
everybody to upgrade is not the right thing to do.

JB>Anyone can propose new releases on any branches (including old ones).

log4j pmc denies migrating from SVN to Git, so it is hard to even propose a
PR :( (see [4] in the first message)

JB>If you need my support/help on this

Did you mean "help with resurrecting" or "help with convincing log4j pmc
accepting PRs"? :)

Vladimir



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Looking for a champion: resurrect log4j 1.x

[Vladimir Sitnikov]

JB>Anyone can propose new releases on any branches (including old ones).
JB>If you need my support/help on this, please let me know.

I and the other contributors tried to suggest PRs, however, log4j pmc
actively denies them.
They suggest contributors should focus on polishing log4j 1->2
compatibility layer.
Making the compatibility 100% correct is hard, so I believe forcing
everybody to upgrade is not the right thing to do.

JB>Anyone can propose new releases on any branches (including old ones).

log4j pmc denies migrating from SVN to Git, so it is hard to even propose a
PR :( (see [4] in the first message)

JB>If you need my support/help on this

Did you mean "help with resurrecting" or "help with convincing log4j pmc
accepting PRs"? :)

Vladimir

Re: Looking for a champion: resurrect log4j 1.x

[JB Onofré]

Hi

I don’t think you need the incubator there. You can propose to log4j pmc to 
move forward on log4j 1.x. 
Anyone can propose new releases on any branches (including old ones). 
If you need my support/help on this, please let me know. 

Just my €0.01 ;)

Regards 
JB

> Le 20 déc. 2021 à 08:27, Vladimir Sitnikov  a 
> écrit :
> 
> Hi,
> 
> I want to resurrect log4j 1.x to fix well-known security issues.
> I'm looking for the champion and committers.
> 
> log4j 1.x is a wildly used logging library, so releasing a secured version
> would silence CVE warnings
> all over the world, and it would enable users to focus on more relevant
> tasks than "upgrading from log4j1 to log4j2".
> 
> I do not expect active log4j1 development, however, I would strongly focus
> on fixing the security issues.
> 
> Unfortunately, there are lots of applications that can't easily upgrade to
> log4j2, and they are exposed to security issues.
> I did try my best cooperating with the current logging PMC, and it looks
> like they
> are not interested in fixing 1.x (see [1], [2], [3], [4])
> 
> I'm a member of PMC on Apache JMeter and Apache Calcite projects, so
> I am familiar with the way Apache projects are governed.
> 
> [1]: https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5
> [2]: https://lists.apache.org/thread/hq2m11f1w9yp031r5f65b9h4ym2zy1kc
> [3]: https://lists.apache.org/thread/tw172svxt1q6wds7lt9szyjw2sxjf34n
> [4]: https://lists.apache.org/thread/y89v84okzs76g2yl760vx5yc0w1y4yd8
> 
> Vladimir


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Looking for a champion: resurrect log4j 1.x

[Vladimir Sitnikov]

Hi,

I want to resurrect log4j 1.x to fix well-known security issues.
I'm looking for the champion and committers.

log4j 1.x is a wildly used logging library, so releasing a secured version
would silence CVE warnings
all over the world, and it would enable users to focus on more relevant
tasks than "upgrading from log4j1 to log4j2".

I do not expect active log4j1 development, however, I would strongly focus
on fixing the security issues.

Unfortunately, there are lots of applications that can't easily upgrade to
log4j2, and they are exposed to security issues.
I did try my best cooperating with the current logging PMC, and it looks
like they
are not interested in fixing 1.x (see [1], [2], [3], [4])

I'm a member of PMC on Apache JMeter and Apache Calcite projects, so
I am familiar with the way Apache projects are governed.

[1]: https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5
[2]: https://lists.apache.org/thread/hq2m11f1w9yp031r5f65b9h4ym2zy1kc
[3]: https://lists.apache.org/thread/tw172svxt1q6wds7lt9szyjw2sxjf34n
[4]: https://lists.apache.org/thread/y89v84okzs76g2yl760vx5yc0w1y4yd8

Vladimir