You are viewing a plain text version of this content. The canonical link for it is here.
Posted to discuss@petri.apache.org by Vladimir Sitnikov <si...@gmail.com> on 2022/02/03 12:35:17 UTC
Ressurrect log4j 1.x within the ASF
Hi,
Log4j received worldwide attention in December 2021, which caused a new
wave of discussions for both 1.x and 2.x versions.
Andrew, Ceki, Enrico, Rohit, and I would like to make log4j 1.x releases to
harden
the library and make the world better by improving security worldwide.
We believe that reviving log4j 1.x within the ASF would highlight that the
ASF cares about users.
Dave suggested (see
https://lists.apache.org/thread/xkmlbg3f075vxtm9jolt16o6brtgyzo8 )
an option to create a new PMC for log4j 1.x provided initial committers are
identified, then Dave suggested posting at discuss@petri.a.o.
We have 3 Apache Members onboard: Andrew, Ceki, Enrico.
Would you please advise us on the next steps?
Unfortunately, we see no way to proceed with log4j 1.x releases with the
current
Logging PMC (see below) as it would hurt both parties.
The Logging PMC wants to maintain 2.x, they do not want to maintain 1.x,
and they have no time and resources for 1.x.
Moving log4j 1.x to Commons PMC does not sound feasible since many members
of
Logging PMC are members of Commons PMC (e.g. Christian Grobmeier,
Gary D. Gregory, Matt Sicker, Ralph Goers), and they all vetoed releasing
newer log4j 1.x versions.
Frankly speaking, I doubt they would have a different opinion as they wear
Commons PMC hats rather than Logging PMC ones.
What we ultimately want is to release secured versions, and we did hope the
Logging PMC
would accept fixes for the critical issues in log4j 1.x.
Unfortunately, Logging PMC is actively preventing the revival of log4j 1.x.
Community around log4j 1.x
========
Andrew, Ceki, Enrico, Rohit, and I (in alphabetical order) agreed we could
volunteer to fix log4j 1.x security
and maybe other critical issues, so the current users of log4j 1.x could
update and make their applications more secure.
https://whimsy.apache.org/roster/committer/apurtell
https://whimsy.apache.org/roster/committer/ceki
https://whimsy.apache.org/roster/committer/eolivelli
https://whimsy.apache.org/roster/committer/rohit
https://whimsy.apache.org/roster/committer/vladimirsitnikov
We value both the ASF and the users.
We acknowledge log4j 1.x would be a strange choice for the newly created
projects.
However, we believe releasing security fixes for 1.x is still important as
there are many applications that integrate log4j 1.x.
Reasons to keep log4j 1.x community within the ASF
========
Technically speaking, there’s a possibility to fork log4j outside of the
ASF.
There are many forks flying around: RedHat, Atlassian, and probably
other companies and individuals make and release their forks of log4j.
Unfortunately, the forks will never get traction as the users won’t know
the fork exists.
Dependabot and Renovatebot will never suggest “update Apache log4j 1.x to
Acme log 1.x”.
Making the release within the ASF would unify the users and avoid
duplication of effort.
We believe it would make the world more secure, and it would resolve
“oh, your app is using a vulnerable log4j 1.x, you must resolve it
immediately” cases.
Of course, the mere existence of CVE for log4j 1.x does not make the
application
immediately vulnerable, however, it would be so much better if the
problematic classes
could be separated into their own jar files, so the users know they are
using a hardened version.
log4j 1.x-2.x compatibility bridge
========
The bridge exists for a while, however:
a) It fails in non-trivial cases. It is still experimental, there are known
and
documented limitations, and there might be unknown limitations
b) The effort to upgrade old applications is non-trivial: the app might
fail to startup or
it might fail in certain business cases only. It might require updating
maintenance
scripts and procedures yielding no business value
c) The applications that use log4j 1.x are often fine with 1.x feature set,
and often
the only reason for updating 1.x is to resolve known security issues. In
that case,
it is wasteful to spend resources for migrating to log4j 2.x.
Log4j 1.x was EOL long ago
========
It is not rare when the software is maintained (e.g. reconfigured) and
developed by
different teams or even different companies.
The set of features and bugs in 1.x is often enough, however, the CVEs in
December 2021
highlighted the log4j topic once again even though the CVEs mentioned 2.x
only.
In that case, upgrading all the old apps to 2.x would be a great waste of
time for
both companies developing the software and their customers who eventually
need to learn different approaches to the configuration, update their
automatic scripts, and so on.
I can’t tell my story, however, Jason Pyeron mentioned
projects that can't migrate:
https://lists.apache.org/thread/b5b2vpbgjd72bsl2sw7thpbqh30spfbk
Apache Hadoop has issues with migrating to 2.x:
https://lists.apache.org/thread/gvfb3jkg6t11cyds4jmpo7lrswmx28w3
I am sure there are a lot of stories like that.
As the Logging PMC resolved 2.x CVEs, I realized it would be great
if there was a way to harden 1.x within the ASF.
Then the users could update 1.x and have more time with their families
rather than spending time on wasteful migration off 1.x.
So I posted my suggestion to dev@logging after 2.15 and 2.16 releases.
By that time I assumed 2 security releases were more or less enough to
resolve the CVEs.
Working with the Logging PMC
========
I tried my best in working with the current Logging PMC, however,
they are not willing to improve log4j 1.x :(
I started by asking Logging PMC about the possibility to release 1.x with
CVE fixes (see [1]),
and I suggested my help with doing that.
The PMC expressed no opinion on the idea to fix 1.x.
Several people (outside of Logging) picked up the idea.
For instance, Leo Simons suggested changes to make the project buildable
(see [2]).
Reviewing patches is way easier with GitHub pulls requests,
so I suggested that 1.x should flip from SVN to Git as its primary VCS:
https://lists.apache.org/thread/ssbdg44gy7txzl16xxd097t7orco52g2
SVN -> Git is a trivial change (the only action needed from PMC was to
agree on Git),
however, it took a lot of time to make PMC agree Git was a good idea.
Then Ralph (member of Logging PMC) suggested they won’t release 1.x,
and that I should go with the incubator (see [3]).
That is why I started “Looking for a champion: resurrect log4j 1.x” thread
in an attempt to re-incubate 1.x:
https://lists.apache.org/thread/mx667xg7rps5b7rhgr7pojmj26o9qzq7
Dave (and maybe others) suggested I should re-iterate with Logging PMC, and
I did that.
I reviewed existing patches, and I submitted a minimal pull request to make
log4j 1.x buildable (see [4], [5]).
Unfortunately, Logging PMC declined my suggestions.
Frankly speaking, it is extremely frustrating that even such
trivial changes as “make the code buildable”, “make tests pass”, “add CI
job” face vetos from the PMC.
I do understand they have a hard time caused by 2.x CVEs, however, they do
respond to 1.x-related mails.
It is frustrating when the only responses are “-1”, “I’ve not really heard
anybody else say” (see [6]),
and so on, especially when there are people who volunteer to do the work.
Logging PMC insists that 1.x-2.x bridge is the only possible option.
However, we created https://github.com/qos-ch/reload4j fork, and it proves
there's no issue with making log4j 1.x code buildable, and there's no issue
with fixing CVEs.
Ceki (still a committer in Logging) attempted to create a branch (just a
Git branch without changes) for
hardening 1.x, and it was vetoed based on “1.x is EOL”:
https://lists.apache.org/thread/4639nvg79j5jpxrx5bsosnt7k2c16ysv
Finally, the Logging PMC re-announced the end of life for 1.x:
https://lists.apache.org/thread/dlz8nyrsvffmgq29d354s0l484lfc83w
They say they will close all pull requests as “won’t fix” :(
[1] https://lists.apache.org/thread/tc6twt82f51c093km8r3qxthgj9lls1r
[2] https://lists.apache.org/thread/sb6qt1lmjj53dcb7hx7vyb19kdvfm36g
[3] https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5
[4] https://github.com/apache/logging-log4j1/pull/18
[5] https://issues.apache.org/jira/browse/LOG4J2-3301
[6] https://lists.apache.org/thread/1fkwr4lhdglvxnn5dncjxvc7n824wsf6
Regards,
Andrew, Ceki, Enrico, Rohit, Vladimir
Re: Ressurrect log4j 1.x within the ASF
Posted by Dave Fisher <wa...@apache.org>.
I just reviewed https://projects.apache.org which seems to confuse Projects and Products.
Read my notes as:
1. When I write project that is “Committee”.
2. When I write product that is “Projects”
I’ve written to dev@community.a.o about this confusion.
Regards,
Dave
> On Feb 4, 2022, at 7:52 AM, Dave Fisher <wa...@apache.org> wrote:
>
>
>
>> On Feb 3, 2022, at 12:20 PM, Vladimir Sitnikov <vl...@apache.org> wrote:
>>
>>> But what are we to do with the name "log4j"? That is "owned" (to
>>> use a term) by the Apache Logging PMC
>>
>> AFAIK, log4j has emerged in Commons PMC, and then it has been transferred
>> to Logging PMC, so there should not be much confusion if a project is moved to
>> another PMC.
>
> Log4j is a product name. Logging is a project name. Log4J 1 and Log4J 2 are product names of the Apache Logging project.
>
>>
>>> It might create confusion across our
>>> communities,
>>
>> Greg,
>> Renaming the project would cause confusion across users.
>
> Apache “ACME” could be the name of your proposed projects
>
>>
>> Here are the issues that would inevitably cause pain for the users:
>> 1) We would probably have to replace Maven coordinates from log4j:log4j with something else,
>> and it would defeat Dependabot and other auto-update tools.
>> How would people know they need to replace vulnerable log4j 1.x with acmelog 1.x?
>
> You’ve pointed out that the coordinates are differently patterned between Log4J 1 and Log4J 2. ”ACME” folder on dist.apache.org
>
>> 2) The alternative name creates a case for yet another classpath conflict.
>> If users happen to have both reload4j.jar and log4j-1.2.jar at the same time, they would have
>> weird issues. It can happen if some of the dependencies move to the new fork,
>> and some of the dependencies keep using the old log4j 1.x.
>> Maven is still used in ~60-70% of projects, and Maven has absolutely no way to prevent
>> that conflict automatically :(
>> 3) If we continue with reload4j, we lose all the Google and StackOverflow results.
>> That creates obstacles for the community out of thin air.
>
> Well, how does “ACME” avoid creating confusion amongst users between responsibility for Log4J 1 and Log4J 2?
>
> Google and StackOverflow own those answers and not Apache Logging. You are creating a new project community for Log4J 1 that splits from Apache Logging.
>
>> 4) Renaming the project (and the jar) would trigger security and licensing paperwork
>> all over the place as users would have to re-evaluate if they can use reload4j.
>> Releasing the same thing as log4j 1.2.18 is way easier to understand and convey.
>
> Project names and product names are separate although they are the same for most Apache communities. Apache Logging has several Log4* products. Changing the Project name is required. Changing the product name might be negotiable.
>
>> 5) We would have to use org.apache.log4j package names anyway
>> for backward compatibility reasons, so users would still be confused with
>> "why log4j is called reload4j?!".
>
> The purpose of your community is to provide a drop in replacement with as little friction as possible. It is likely that package names can remain. Any new packages should likely get new package names, but I doubt those are in your plans.
>
>> 6) Java logging is already non-trivial, and adding a new name would make it even harder.
>> See https://blog.gradle.org/addressing-logging-complexity-capabilities
>>
>>> Is that even workable?
>>
>> Of course, we can weigh options, however, I think renaming the project voids the effort.
>> I am open here (including a verbal conversation), however, I think log4j and log4j2 are
>> significantly different names, and renaming log4j 1.x to another name would be an overreaction
>> adding extra burden on the users.
>>
>> 1) Users worldwide would appreciate security and stability releases for log4j 1.x under the old name and old Maven coordinates (see 1..5 above).
>> 2) Any resolution (renaming log4j to another name, keeping log4j 1.x name, or rejecting the fork within the ASF) would cause tension for certain individuals.
>>
>> I truly do not understand what causes the tension.
>> Of course, I can imagine that Logging PMC might want that everybody
>> should migrate all their logging to log4j 2.x, however, if that is really the case,
>> they should reach the goal by building the community around 2.x and releasing
>> better software rather than denying security fixes to 1.x branch.
>>
>> Our goal is to provide secure and stable log4j 1.x,
>> so the users can just update log4j 1.2.17 to the newer version and be fine with it.
>>
>> I would say that renaming the project (and renaming Maven coordinates)
>> would bring even more confusion.
>>
>>> Basically, how do we avoid undermining Apache Logging? I do hope they'd be
>>> more than happy to point log4j 1.x users to a new ACME project, but likely
>>> only if a new name is selected to avoid confusion.
>>
>> Frankly speaking, I did hope Apache Logging would be more than happy to accept the security
>> and stability fixes for log4j 1.x.
>> Unfortunately, they clearly deny any work on 1.x, so I do not understand why
>> renaming the project would make any difference.
>
> Please reflect on the difference between project name and product name.
>>
>> Does that mean the rename is done only to make Logging PMC happy (~16 persons)
>> at a cost of causing confusion for everyone using log4j 1.x?
>>
>> Note: log4j2 is using different Maven coordinates, so releasing newer 1.x versions
>> should be just fine for existing 1.x and 2.x users.
>
> I missed this before.
>
> HTH,
> Dave
>
>>
>> Vladimir
>
Re: Ressurrect log4j 1.x within the ASF
Posted by Dave Fisher <wa...@comcast.net>.
Sent from my iPhone
> On Feb 7, 2022, at 4:43 AM, Vladimir Sitnikov <si...@gmail.com> wrote:
>
> Vladimir> Project name (Committee): Apache Reload4j
> Dave>Yes. Assuming there are no trademark issues.
>
> Ceki, would you please confirm if "Apache Reload4j" can be used without
> trademark issues?
Please follow the process here https://incubator.apache.org/guides/names.html#conducting_a_suitable_name_search
>
> Dave>That product name belongs to Logging, but maybe something like Apache
> Log4J Classic or Apache ClassicLog4J could work.
>
> log4j1 might be even better.
Sure
>
> ---
>
> Dave, it looks like we have naming ideas. How do we negotiate and what are
> the next steps?
(1) Suitable name search via the link above.
(2) Determining the mission statement for the project which is also included in the direct TLP resolution for either this or the next board meeting. This link [1] gives links to examples which will help write the statement.
(3) We should discuss the communication strategy with the board and the logging PMC. IMO once the Direct to TLP resolution is written, you should send it to the board and start a DISCUSS thread on board@apache.org. There should be some discussion about why, but I would advise simply mentioning that the Logging PMC is not interested in maintaining Log4J 1 and this group is. Keep it short and direct.
(4) We’ll need to plan the infrastructure requests, but let’s see how quickly the Direct to TLP process happens.
Here to help,
Dave
[1] https://incubator.apache.org/guides/graduation.html#preparing_a_charter
>
> Vladimir
Re: Ressurrect log4j 1.x within the ASF
Posted by Vladimir Sitnikov <si...@gmail.com>.
Vladimir> Project name (Committee): Apache Reload4j
Dave>Yes. Assuming there are no trademark issues.
Ceki, would you please confirm if "Apache Reload4j" can be used without
trademark issues?
Dave>That product name belongs to Logging, but maybe something like Apache
Log4J Classic or Apache ClassicLog4J could work.
log4j1 might be even better.
---
Dave, it looks like we have naming ideas. How do we negotiate and what are
the next steps?
Vladimir
Re: Ressurrect log4j 1.x within the ASF
Posted by Dave Fisher <wa...@apache.org>.
> On Feb 4, 2022, at 8:46 AM, Vladimir Sitnikov <si...@gmail.com> wrote:
>
> Dave, thank you for the clarification, you nailed my confusion.
>
>> Changing the Project name is required. Changing the product name might be
> negotiable.
>
> I would love to
> a) Keep Maven coordinates to minimize friction for users
> b) Keep product name to make error lookup easier
> c) Add notes to the existing log4j 1.x CVEs that the fix is available in
> the relevant 1.x release
>
> However, just like you said, the project name should be different.
>
> Do you think the following might work?
>
> Project name (Committee): Apache Reload4j
Yes. Assuming there are no trademark issues.
> Webpage: reload4j.apache.org
That follows apache standards.
> Product name: Apache Log4j
That product name belongs to Logging, but maybe something like Apache Log4J Classic or Apache ClassicLog4J could work.
> Maven coordinates: log4j:log4j
Sure.
Regards,
Dave
>
> Vladimir
Re: Ressurrect log4j 1.x within the ASF
Posted by Vladimir Sitnikov <si...@gmail.com>.
Dave, thank you for the clarification, you nailed my confusion.
>Changing the Project name is required. Changing the product name might be
negotiable.
I would love to
a) Keep Maven coordinates to minimize friction for users
b) Keep product name to make error lookup easier
c) Add notes to the existing log4j 1.x CVEs that the fix is available in
the relevant 1.x release
However, just like you said, the project name should be different.
Do you think the following might work?
Project name (Committee): Apache Reload4j
Webpage: reload4j.apache.org
Product name: Apache Log4j
Maven coordinates: log4j:log4j
Vladimir
Re: Ressurrect log4j 1.x within the ASF
Posted by Dave Fisher <wa...@apache.org>.
> On Feb 3, 2022, at 12:20 PM, Vladimir Sitnikov <vl...@apache.org> wrote:
>
>> But what are we to do with the name "log4j"? That is "owned" (to
>> use a term) by the Apache Logging PMC
>
> AFAIK, log4j has emerged in Commons PMC, and then it has been transferred
> to Logging PMC, so there should not be much confusion if a project is moved to
> another PMC.
Log4j is a product name. Logging is a project name. Log4J 1 and Log4J 2 are product names of the Apache Logging project.
>
>> It might create confusion across our
>> communities,
>
> Greg,
> Renaming the project would cause confusion across users.
Apache “ACME” could be the name of your proposed projects
>
> Here are the issues that would inevitably cause pain for the users:
> 1) We would probably have to replace Maven coordinates from log4j:log4j with something else,
> and it would defeat Dependabot and other auto-update tools.
> How would people know they need to replace vulnerable log4j 1.x with acmelog 1.x?
You’ve pointed out that the coordinates are differently patterned between Log4J 1 and Log4J 2. ”ACME” folder on dist.apache.org
> 2) The alternative name creates a case for yet another classpath conflict.
> If users happen to have both reload4j.jar and log4j-1.2.jar at the same time, they would have
> weird issues. It can happen if some of the dependencies move to the new fork,
> and some of the dependencies keep using the old log4j 1.x.
> Maven is still used in ~60-70% of projects, and Maven has absolutely no way to prevent
> that conflict automatically :(
> 3) If we continue with reload4j, we lose all the Google and StackOverflow results.
> That creates obstacles for the community out of thin air.
Well, how does “ACME” avoid creating confusion amongst users between responsibility for Log4J 1 and Log4J 2?
Google and StackOverflow own those answers and not Apache Logging. You are creating a new project community for Log4J 1 that splits from Apache Logging.
> 4) Renaming the project (and the jar) would trigger security and licensing paperwork
> all over the place as users would have to re-evaluate if they can use reload4j.
> Releasing the same thing as log4j 1.2.18 is way easier to understand and convey.
Project names and product names are separate although they are the same for most Apache communities. Apache Logging has several Log4* products. Changing the Project name is required. Changing the product name might be negotiable.
> 5) We would have to use org.apache.log4j package names anyway
> for backward compatibility reasons, so users would still be confused with
> "why log4j is called reload4j?!".
The purpose of your community is to provide a drop in replacement with as little friction as possible. It is likely that package names can remain. Any new packages should likely get new package names, but I doubt those are in your plans.
> 6) Java logging is already non-trivial, and adding a new name would make it even harder.
> See https://blog.gradle.org/addressing-logging-complexity-capabilities
>
>> Is that even workable?
>
> Of course, we can weigh options, however, I think renaming the project voids the effort.
> I am open here (including a verbal conversation), however, I think log4j and log4j2 are
> significantly different names, and renaming log4j 1.x to another name would be an overreaction
> adding extra burden on the users.
>
> 1) Users worldwide would appreciate security and stability releases for log4j 1.x under the old name and old Maven coordinates (see 1..5 above).
> 2) Any resolution (renaming log4j to another name, keeping log4j 1.x name, or rejecting the fork within the ASF) would cause tension for certain individuals.
>
> I truly do not understand what causes the tension.
> Of course, I can imagine that Logging PMC might want that everybody
> should migrate all their logging to log4j 2.x, however, if that is really the case,
> they should reach the goal by building the community around 2.x and releasing
> better software rather than denying security fixes to 1.x branch.
>
> Our goal is to provide secure and stable log4j 1.x,
> so the users can just update log4j 1.2.17 to the newer version and be fine with it.
>
> I would say that renaming the project (and renaming Maven coordinates)
> would bring even more confusion.
>
>> Basically, how do we avoid undermining Apache Logging? I do hope they'd be
>> more than happy to point log4j 1.x users to a new ACME project, but likely
>> only if a new name is selected to avoid confusion.
>
> Frankly speaking, I did hope Apache Logging would be more than happy to accept the security
> and stability fixes for log4j 1.x.
> Unfortunately, they clearly deny any work on 1.x, so I do not understand why
> renaming the project would make any difference.
Please reflect on the difference between project name and product name.
>
> Does that mean the rename is done only to make Logging PMC happy (~16 persons)
> at a cost of causing confusion for everyone using log4j 1.x?
>
> Note: log4j2 is using different Maven coordinates, so releasing newer 1.x versions
> should be just fine for existing 1.x and 2.x users.
I missed this before.
HTH,
Dave
>
> Vladimir
Re: Ressurrect log4j 1.x within the ASF
Posted by Vladimir Sitnikov <vl...@apache.org>.
>But what are we to do with the name "log4j"? That is "owned" (to
> use a term) by the Apache Logging PMC
AFAIK, log4j has emerged in Commons PMC, and then it has been transferred
to Logging PMC, so there should not be much confusion if a project is moved to
another PMC.
>It might create confusion across our
> communities,
Greg,
Renaming the project would cause confusion across users.
Here are the issues that would inevitably cause pain for the users:
1) We would probably have to replace Maven coordinates from log4j:log4j with something else,
and it would defeat Dependabot and other auto-update tools.
How would people know they need to replace vulnerable log4j 1.x with acmelog 1.x?
2) The alternative name creates a case for yet another classpath conflict.
If users happen to have both reload4j.jar and log4j-1.2.jar at the same time, they would have
weird issues. It can happen if some of the dependencies move to the new fork,
and some of the dependencies keep using the old log4j 1.x.
Maven is still used in ~60-70% of projects, and Maven has absolutely no way to prevent
that conflict automatically :(
3) If we continue with reload4j, we lose all the Google and StackOverflow results.
That creates obstacles for the community out of thin air.
4) Renaming the project (and the jar) would trigger security and licensing paperwork
all over the place as users would have to re-evaluate if they can use reload4j.
Releasing the same thing as log4j 1.2.18 is way easier to understand and convey.
5) We would have to use org.apache.log4j package names anyway
for backward compatibility reasons, so users would still be confused with
"why log4j is called reload4j?!".
6) Java logging is already non-trivial, and adding a new name would make it even harder.
See https://blog.gradle.org/addressing-logging-complexity-capabilities
> Is that even workable?
Of course, we can weigh options, however, I think renaming the project voids the effort.
I am open here (including a verbal conversation), however, I think log4j and log4j2 are
significantly different names, and renaming log4j 1.x to another name would be an overreaction
adding extra burden on the users.
1) Users worldwide would appreciate security and stability releases for log4j 1.x under the old name and old Maven coordinates (see 1..5 above).
2) Any resolution (renaming log4j to another name, keeping log4j 1.x name, or rejecting the fork within the ASF) would cause tension for certain individuals.
I truly do not understand what causes the tension.
Of course, I can imagine that Logging PMC might want that everybody
should migrate all their logging to log4j 2.x, however, if that is really the case,
they should reach the goal by building the community around 2.x and releasing
better software rather than denying security fixes to 1.x branch.
Our goal is to provide secure and stable log4j 1.x,
so the users can just update log4j 1.2.17 to the newer version and be fine with it.
I would say that renaming the project (and renaming Maven coordinates)
would bring even more confusion.
> Basically, how do we avoid undermining Apache Logging? I do hope they'd be
> more than happy to point log4j 1.x users to a new ACME project, but likely
> only if a new name is selected to avoid confusion.
Frankly speaking, I did hope Apache Logging would be more than happy to accept the security
and stability fixes for log4j 1.x.
Unfortunately, they clearly deny any work on 1.x, so I do not understand why
renaming the project would make any difference.
Does that mean the rename is done only to make Logging PMC happy (~16 persons)
at a cost of causing confusion for everyone using log4j 1.x?
Note: log4j2 is using different Maven coordinates, so releasing newer 1.x versions
should be just fine for existing 1.x and 2.x users.
Vladimir
Re: Ressurrect log4j 1.x within the ASF
Posted by Vladimir Sitnikov <vl...@apache.org>.
Dave> (2) is it technically feasible to share the org.apache.logging.log4j co-ordinates with Apache Logging without confusing the users of Log4J 2.X?
log4j used log4j:log4j:1.2.17 coordinates, and it does not conflict with
org.apache.logging.log4j:log4j.
Users already know how to deal with log4j:log4j and org.apache.logging.log4j:log4j.
Does that make sense?
Vladimir
Re: Ressurrect log4j 1.x within the ASF
Posted by Dave Fisher <wa...@apache.org>.
> On Feb 3, 2022, at 5:33 AM, Greg Stein <gs...@gmail.com> wrote:
>
> On Thu, Feb 3, 2022 at 6:35 AM Vladimir Sitnikov <
> sitnikov.vladimir@gmail.com> wrote:
>
>> Hi,
>>
>> Log4j received worldwide attention in December 2021, which caused a new
>> wave of discussions for both 1.x and 2.x versions.
>>
>> Andrew, Ceki, Enrico, Rohit, and I would like to make log4j 1.x releases to
>> harden
>> the library and make the world better by improving security worldwide.
>> We believe that reviving log4j 1.x within the ASF would highlight that the
>> ASF cares about users.
>>
>> Dave suggested (see
>> https://lists.apache.org/thread/xkmlbg3f075vxtm9jolt16o6brtgyzo8 )
>> an option to create a new PMC for log4j 1.x provided initial committers are
>> identified, then Dave suggested posting at discuss@petri.a.o.
>>
>> We have 3 Apache Members onboard: Andrew, Ceki, Enrico.
>>
>> Would you please advise us on the next steps?
>
>
> So Apache Petri is about helping existing communities to shift towards an
> "Apache style" system ("The Apache Way"), and when that is accomplished, to
> request the Board to construct a PMC for that community to operate within
> the ASF.
>
> I have no doubt that the people here understand how to run such a
> community. But what are we to do with the name "log4j"? That is "owned" (to
> use a term) by the Apache Logging PMC. It is unclear to me, whether
> $newProject can use that name. It might create confusion across our
> communities, or a tension, to have multiple people pulling ropes on that
> name.
>
> Thus, is there a possibility to market (say) "ACME Logging, to fix your
> log4j 1.x issues"? Or is there a possibility that Apache Logging will post
> on their website "For log4j 1.x issues, see Apache ACME"
>
> Basically, how do we avoid undermining Apache Logging? I do hope they'd be
> more than happy to point log4j 1.x users to a new ACME project, but likely
> only if a new name is selected to avoid confusion.
>
> Is that even workable?
There are really two issues.
(1) A good project name the does not conflict with Apache Logging and their Log4<lang> product naming style.
The new project name needs to be solved first.
>> Unfortunately, the forks will never get traction as the users won’t know
>> the fork exists.
>> Dependabot and Renovatebot will never suggest “update Apache log4j 1.x to
>> Acme log 1.x”.
(2) is it technically feasible to share the org.apache.logging.log4j co-ordinates with Apache Logging without confusing the users of Log4J 2.X?
Have a look at https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j and it looks like this may be a very difficult technical hurdle.
Regards,
Dave
>
> Cheers,
> -g
Re: Ressurrect log4j 1.x within the ASF
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Feb 3, 2022 at 6:35 AM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> Hi,
>
> Log4j received worldwide attention in December 2021, which caused a new
> wave of discussions for both 1.x and 2.x versions.
>
> Andrew, Ceki, Enrico, Rohit, and I would like to make log4j 1.x releases to
> harden
> the library and make the world better by improving security worldwide.
> We believe that reviving log4j 1.x within the ASF would highlight that the
> ASF cares about users.
>
> Dave suggested (see
> https://lists.apache.org/thread/xkmlbg3f075vxtm9jolt16o6brtgyzo8 )
> an option to create a new PMC for log4j 1.x provided initial committers are
> identified, then Dave suggested posting at discuss@petri.a.o.
>
> We have 3 Apache Members onboard: Andrew, Ceki, Enrico.
>
> Would you please advise us on the next steps?
So Apache Petri is about helping existing communities to shift towards an
"Apache style" system ("The Apache Way"), and when that is accomplished, to
request the Board to construct a PMC for that community to operate within
the ASF.
I have no doubt that the people here understand how to run such a
community. But what are we to do with the name "log4j"? That is "owned" (to
use a term) by the Apache Logging PMC. It is unclear to me, whether
$newProject can use that name. It might create confusion across our
communities, or a tension, to have multiple people pulling ropes on that
name.
Thus, is there a possibility to market (say) "ACME Logging, to fix your
log4j 1.x issues"? Or is there a possibility that Apache Logging will post
on their website "For log4j 1.x issues, see Apache ACME"
Basically, how do we avoid undermining Apache Logging? I do hope they'd be
more than happy to point log4j 1.x users to a new ACME project, but likely
only if a new name is selected to avoid confusion.
Is that even workable?
Cheers,
-g