Re: Resurrecting log4j 1.x

[Christian Grobmeier]

Hi

On Fri, Dec 24, 2021, at 06:29, Vladimir Sitnikov wrote:
> Christian>Here is some more information on how we develop software:
>
> Christian, I'm a member of PMC in Apache JMeter and Apache Calcite, ok?

I was not aware of that, but the way you discussed looked like it was helpful 
to send that link.

> Could you please stop going in circles and just agree to open apache/log4j
> Git for writes?

No. We discuss, I listen to arguments and/or give mine and then we have a vote. 
A vote is already done and I can express my opinion as I wish too.

This is also not the tone of an email we send around to each other here.

> Are there another viable alternatives?

Yes.

> Note, that INFRA says they can easily reopen apache/log4j, and the only
> missing bit
> is exactly the one I asked 16 December.

if done wrong, we commit ourselves to maintain an EOL product and give wrong 
expectations. I want this PMC to be very sure about what we do and careful 
about how our actions look to the public.

I will not agree to anything just because you think it is right. We all need to 
think it is right. How can we know, you actually plan to work on it after we 
open it? Send in patches, we review, and then we can always make it up for 
writes and apply them. As an ASF fellow you know how this works.

Thanks,
Christian

>
> Vladimir

Re: Resurrecting log4j 1.x

[Volkan Yazıcı]

Okay, my mistake, that makes it 3 people.

The PMC is already in the progress of resurrecting 1.x. Once the repo is
up, we will be happy to review and merge your PRs, granted they only target
security vulnerabilities.

On Fri, Dec 24, 2021 at 9:40 AM Andrew Marlow 
wrote:

> On Thu, 23 Dec 2021 at 15:13, Volkan Yazıcı  wrote:
>
> > Vladimir, mind helping us to quantify this "need", please? To the best of
> > my knowledge, nobody has reached out to us with such a request except you
> > and Leo.
>
>
> That's not quite right. A while ago I asked if the RedHat fix could be
> added to log4j-1 to create version 1.2.18. This was to fix
> https://www.cvedetails.com/cve/CVE-2019-17571. RedHat have already
> implemented a fix for this which is included in RHEL. It was pointed out
> then that since log4j-1 is EOL no further releases would be made. I was
> very disappointed. Now people are talking about resurrecting log4j-1 just
> for fixing CVEs I would like people to consider doing this one first
> please.
>
> The Red Hat announcement of their fix can be seen at
> https://access.redhat.com/security/cve/cve-2019-17571
> Back in the day I tracked down their code fix and satisfied myself that it
> does the job. It was a bit of effort to track down but I'm sure Red hat
> would help if we asked them nicely.
>

Re: Resurrecting log4j 1.x

[Andrew Marlow]

On Thu, 23 Dec 2021 at 15:13, Volkan Yazıcı  wrote:

> Vladimir, mind helping us to quantify this "need", please? To the best of
> my knowledge, nobody has reached out to us with such a request except you
> and Leo.


That's not quite right. A while ago I asked if the RedHat fix could be
added to log4j-1 to create version 1.2.18. This was to fix
https://www.cvedetails.com/cve/CVE-2019-17571. RedHat have already
implemented a fix for this which is included in RHEL. It was pointed out
then that since log4j-1 is EOL no further releases would be made. I was
very disappointed. Now people are talking about resurrecting log4j-1 just
for fixing CVEs I would like people to consider doing this one first
please.

The Red Hat announcement of their fix can be seen at
https://access.redhat.com/security/cve/cve-2019-17571
Back in the day I tracked down their code fix and satisfied myself that it
does the job. It was a bit of effort to track down but I'm sure Red hat
would help if we asked them nicely.

Re: Resurrecting log4j 1.x

[Remko Popma]

Vladimir,

There is a vote thread in progress (
https://lists.apache.org/thread/0rk0nr0pv9p2945jsrs9pp2ys57wksn3). You and
I both voted on that thread.
Looking at the number of +1 votes on that voting thread, surely you can see
that this repo will be created, and not only that, it will be created
*exactly the way you asked for*.
As far as I can see, there is no missing bit any more.

So, maybe I am missing something, but I cannot see the point of your
message to Christian.
Why use harsh words to push for something that is already happening?

Personally I enjoy being on the Logging PMC because we have a nice
community where people really listen and are careful how they phrase things.
I think we truly try to embody Apache's code of conduct
 as well as
the participation
guidelines  in all our
communications.

We are all only human, doing the best we can.
Let's be kind to each other.

Remko


On Fri, Dec 24, 2021 at 2:30 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> Christian>Here is some more information on how we develop software:
>
> Christian, I'm a member of PMC in Apache JMeter and Apache Calcite, ok?
>
> >as a community, need to find consensus first
>
> Could you please stop going in circles and just agree to open apache/log4j
> Git for writes?
> Are there another viable alternatives?
>
> 14 December I suggest shipping 1.2.18
> 16 December I started "[VOTE] Move log4j 1.x from SVN to Git, use the
> current apache/log4j mirror"
> https://lists.apache.org/thread/ssbdg44gy7txzl16xxd097t7orco52g2
> ^^ this is exactly to gather PMC consensus on proceeding the work on log4j
> 1.x in apache/log4j git repo.
> As it turns out later, the email consensus on opening Git for writes was
> absolutely needed.
> lots of mails...
> 21 December Remko says "migration to Git will happen"
> https://lists.apache.org/thread/y463on8fbvkkc0k0wpzo68ywmogg6327
> Then, out of a sudden Ralph creates a new Git repo instead of continuing in
> the initially requested one.
>
> 23 December I create INFRA-22654 so Logging PMC understands that
> the only missing bit is their consensus on reopening apache/log4j
>
> Note, that INFRA says they can easily reopen apache/log4j, and the only
> missing bit
> is exactly the one I asked 16 December.
>
> Vladimir
>

Re: Resurrecting log4j 1.x

[Vladimir Sitnikov]

Christian>Here is some more information on how we develop software:

Christian, I'm a member of PMC in Apache JMeter and Apache Calcite, ok?

>as a community, need to find consensus first

Could you please stop going in circles and just agree to open apache/log4j
Git for writes?
Are there another viable alternatives?

14 December I suggest shipping 1.2.18
16 December I started "[VOTE] Move log4j 1.x from SVN to Git, use the
current apache/log4j mirror"
https://lists.apache.org/thread/ssbdg44gy7txzl16xxd097t7orco52g2
^^ this is exactly to gather PMC consensus on proceeding the work on log4j
1.x in apache/log4j git repo.
As it turns out later, the email consensus on opening Git for writes was
absolutely needed.
lots of mails...
21 December Remko says "migration to Git will happen"
https://lists.apache.org/thread/y463on8fbvkkc0k0wpzo68ywmogg6327
Then, out of a sudden Ralph creates a new Git repo instead of continuing in
the initially requested one.

23 December I create INFRA-22654 so Logging PMC understands that
the only missing bit is their consensus on reopening apache/log4j

Note, that INFRA says they can easily reopen apache/log4j, and the only
missing bit
is exactly the one I asked 16 December.

Vladimir

Re: Resurrecting log4j 1.x

[Christian Grobmeier]

Hello Vladimir,

On Thu, Dec 23, 2021, at 20:58, Vladimir Sitnikov wrote:
> Christian>if you send in patches there are people who would apply them
>
> Thank you.
> Let us see what INFRA says regarding https://github.com/apache/log4j in
> https://issues.apache.org/jira/browse/INFRA-22654

This is not an infrastructure issue. As Chris (from Infra) explained, we, as a 
community, need to find consensus first.

In other words, we have to discuss all issues and problems and then make up a 
vote. Only PMC member votes are usually considered binding. Before we reach 
consensus, we should not create any issues - and extra work - for infra.

Here is some more information on how we develop software:
https://www.apache.org/theapacheway/index.html

kind regards,
Christian

>
> Vladimir

Re: Resurrecting log4j 1.x

[Ralph Goers]

Dominik,

The branch named “main” has been created from the v1_2_17 tag. I have created a 
ticket 
to have that branch made the GitHub default branch. Once that is done we can 
rename
trunk to something else or delete the branch entirely.

Ralph

> On Dec 23, 2021, at 1:21 PM, Dominik Psenner  wrote:
> 
> So far it has been discussed to patch 1.2.17. I propose to fork
> logging-log4j1 [1] and base improvements on tag v1_2_17,  de9f0ea. As far
> as I can tell, no additional work is required from Infra or Logging
> Services.
> 
> [1] https://github.com/apache/logging-log4j1
> --
> Sent from my phone. Typos are a kind gift to anyone who happens to find
> them.
> 
> On Thu, Dec 23, 2021, 20:58 Vladimir Sitnikov 
> wrote:
> 
>> Christian>if you send in patches there are people who would apply them
>> 
>> Thank you.
>> Let us see what INFRA says regarding https://github.com/apache/log4j in
>> https://issues.apache.org/jira/browse/INFRA-22654
>> 
>> Vladimir
>> 

Re: Resurrecting log4j 1.x

[Dominik Psenner]

So far it has been discussed to patch 1.2.17. I propose to fork
logging-log4j1 [1] and base improvements on tag v1_2_17,  de9f0ea. As far
as I can tell, no additional work is required from Infra or Logging
Services.

[1] https://github.com/apache/logging-log4j1
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Thu, Dec 23, 2021, 20:58 Vladimir Sitnikov 
wrote:

> Christian>if you send in patches there are people who would apply them
>
> Thank you.
> Let us see what INFRA says regarding https://github.com/apache/log4j in
> https://issues.apache.org/jira/browse/INFRA-22654
>
> Vladimir
>

Re: Resurrecting log4j 1.x

[Vladimir Sitnikov]

Christian>if you send in patches there are people who would apply them

Thank you.
Let us see what INFRA says regarding https://github.com/apache/log4j in
https://issues.apache.org/jira/browse/INFRA-22654

Vladimir

Re: Resurrecting log4j 1.x

[Christian Grobmeier]

Hello

On Thu, Dec 23, 2021, at 18:07, Vladimir Sitnikov wrote:
> Dominik> There are fixes for the flaws of log4j1 available: migrate to
> log4j2
>
> How does migration help me if I want to get 1.x fixed?
> log4j2 is a different product, created by a different team.
> Why should I migrate to log4j2 at all?

There is many reasons why we think log4j2 is better than log4j1 or forked 
products. To get the whole discussion, have a look at the mailing lists around 
2014 or something.

Different team - how does this affect the quality of a product? I remember the 
lengthy discussions about what is good and bad. I can tell that I feel that the 
original committers of log4j2 have spent many thoughts on how to improve 
things. 

Anyway, if you feel there is an urgent need to work on log4j1 then I think so 
be it. The ASF is meritocracy, when there are people around supporting code, 
this code can get released. Personally I don't see a reason to resurrect 
log4j1, but if you see a reason, go ahead.

> Dominik>Is there a concrete need for log4j1 to be patched
>
> 1. I request to get log4j 1.x patched. I can't show my code as it is under
> NDA, so you have to trust me here.

Trust with what exactly? Sorry if I missed something. 

> 2. Enrico Olivelli:
> https://lists.apache.org/thread/llgp7b9v1t081o3215o7xq4zpct1x0b4
> 3. 张铎(Duo Zhang):
> https://lists.apache.org/thread/j8dzoymo5z26sl08o3mvdf0353shcl2m
> 4. Andrew Purtell:
> https://lists.apache.org/thread/kv71f8vrqrhn6tlotqg76gz6khjs11vh

What I see here is basically the need to give better instructions on how to 
upgrade and improve the log4j1 bridge.
Why not working on that but going through the pain of an incubator again?
That said, I feel incubator is wrong, send in patches, become a committer here.

> Do you know migration to 2.x is not a drop-in replacement?
> It might require code or non-trivial configuration changes?
> For instance, if the application extends 1.x appenders, implements
> non-trivial re-configuration logic,
> then it can't upgrade to 2.x in a matter of days or weeks.

People had 7 years to do this. Any help for an upgrade from 1.x to 2.x is very 
welcome I think.

Anyway, despite I am not a big fan of resurrecting a buggy old software if you 
send in patches there are people who would apply them. If we feel there is 
community building around log4j1 we never had a problem with voting in new 
committers, pmc members etc.

You are welcome here, I am looking forward to patches and contributions to 
discuss.

Cheers
Christian

>
> Vladimir

Re: Resurrecting log4j 1.x

[Ralph Goers]

> On Dec 23, 2021, at 10:07 AM, Vladimir Sitnikov  
> wrote:
> 
> 
> Do you know migration to 2.x is not a drop-in replacement?
> It might require code or non-trivial configuration changes?
> For instance, if the application extends 1.x appenders, implements
> non-trivial re-configuration logic,
> then it can't upgrade to 2.x in a matter of days or weeks.

Do you know that for a fact?  Have you tried the support for 1.x appenders, 
etc? I can’t say it always works but I am quite sure you can’t say it never 
does.

Ralph

Re: Resurrecting log4j 1.x

[Vladimir Sitnikov]

Dominik> There are fixes for the flaws of log4j1 available: migrate to
log4j2

How does migration help me if I want to get 1.x fixed?
log4j2 is a different product, created by a different team.
Why should I migrate to log4j2 at all?

Dominik>Is there a concrete need for log4j1 to be patched

1. I request to get log4j 1.x patched. I can't show my code as it is under
NDA, so you have to trust me here.
2. Enrico Olivelli:
https://lists.apache.org/thread/llgp7b9v1t081o3215o7xq4zpct1x0b4
3. 张铎(Duo Zhang):
https://lists.apache.org/thread/j8dzoymo5z26sl08o3mvdf0353shcl2m
4. Andrew Purtell:
https://lists.apache.org/thread/kv71f8vrqrhn6tlotqg76gz6khjs11vh
and so on.

Do you know migration to 2.x is not a drop-in replacement?
It might require code or non-trivial configuration changes?
For instance, if the application extends 1.x appenders, implements
non-trivial re-configuration logic,
then it can't upgrade to 2.x in a matter of days or weeks.

Vladimir

Re: Resurrecting log4j 1.x

[Dominik Psenner]

There are fixes for the flaws of log4j1 available: migrate to log4j2.

Is there a concrete need for log4j1 to be patched and that need cannot be
satisfied by migrating to log4j2?

--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Thu, Dec 23, 2021, 16:39 Vladimir Sitnikov 
wrote:

> Volkan>To the best of
> Volkan>my knowledge, nobody has reached out to us with such a request
> except you
> Volkan>and Leo
>
> I think they just swallowed the pill that "1.x is marked EOL", and they did
> workarounds.
> a) make security team understand "the CVEs of 1.x are not that impactful
> for them"
> b) make internal forks that cut the problematic classes
> c) RedHat having their own fork
>
> However, now log4j went on the radars again,
> so I believe it is way easier (and better) to **fix** CVE than to keep
> explaining that
> "CVEs are not important in this specific case"
>
> I believe you might have access to the download stats for log4j.jar, so you
> can
> relate on the number of its usages.
>
> However, now I realize that the project itself is NOT dead as long as there
> are
> people that want to maintain it.
> It is not wise to say "log4j 1.x is dead" or "log4j 1.x is EOL" when there
> are people
> willing to maintain and release new versions.
> Note: I am not that crazy to do major refactorings in 1.x branch.
>
> So I figured out that releasing log4j 18+ ( : ) would make the lives of
> MANY MANY
> engineers and apps way easier. They would have a drop-in-replacement that
> fixes CVEs,
> improves security all over the world, and so on.
>
> Volkan>I bet it is a matter of months people will start asking for
> Volkan>other fixes once we make a 1.x release.
>
> Now we have a real issue: 1.x has LOTs of known CVEs.
> Could we refrain from theoretical discussions?
>
> Just in case, if in February you observe 10 newly created PRs,
> then it would be a nice problem to have.
>
> If all the PRs turn out to be trivial (e.g. fix NPE in a special case, or
> fix java.version parsing for Java 17),
> then you could just merge them and release 1.2.19
>
> If the review would take noticeable time, you could just say:
> "sorry, I have no time for reviewing the change, please consider creating a
> new PMC for log4j 1.x".
>
> **everybody's** time is limited. If you have no time or desire to
> maintain/support/review/release 1.x,
> then just ask the others do to that (e.g. invite new people to PMC or give
> away 1.x to another PMC).
>
> It might be there will be 10PRs, and there will be *noone* willing to
> review and nobody willing to inherit 1.x
> Then the PRs would be just abandoned.
>
> For instance, the current LOG4J2 JIRA has 809 issues. I doubt you will ever
> fix all of them :)
> So I doubt the question of "what do you do with old issues" or "what if
> there are 100500 open PRs"
> add any value.
>
> WDYT?
>
> Vladimir
>

Re: Resurrecting log4j 1.x

[Vladimir Sitnikov]

>Again: References, please, otherwise you're just making FUD.

CVE-2019-17571
CVE-2021-4104
there might be others

Once again: CVEs in 1.x are real (it exists now).
"pull requests created for 1.x" is theoretical (it does not exist now, and
it does not harm if that really happens).

Vladimir

Re: Resurrecting log4j 1.x

[Gary Gregory]

On Thu, Dec 23, 2021 at 11:14 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> >A, so in fact "1.x has LOTs of known CVEs." translate to one CVE.
>
> This is false.
> There are multiple CVEs.
>

Again: References, please, otherwise you're just making FUD.


> The vulnerabilities have different attack vectors and different
> consequences.
>
> Vladimir
>

Re: Resurrecting log4j 1.x

[Vladimir Sitnikov]

>A, so in fact "1.x has LOTs of known CVEs." translate to one CVE.

This is false.
There are multiple CVEs.
The vulnerabilities have different attack vectors and different
consequences.

Vladimir

Re: Resurrecting log4j 1.x

[Gary Gregory]

On Thu, Dec 23, 2021 at 11:05 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
>
> >Where is this CVE tonnage?
>
> JMSAppender
> JMSSink
> chainsaw
> SocketServer
> infinite recursion (1.x does have some recursive code trying to replace
> variables)
> 
>
> I do not know CVE numbers, yet I just see the bugs are there.


A, so in fact "1.x has LOTs of known CVEs." translate to one CVE.

Thanks for the FUD.

G

>
>
> Vladimir

Re: Resurrecting log4j 1.x

[Vladimir Sitnikov]

>Where is this CVE tonnage?

JMSAppender
JMSSink
chainsaw
SocketServer
infinite recursion (1.x does have some recursive code trying to replace
variables)


I do not know CVE numbers, yet I just see the bugs are there.

Vladimir

Re: Resurrecting log4j 1.x

[Gary Gregory]

>Now we have a real issue: 1.x has LOTs of known CVEs.
>Could we refrain from theoretical discussions?

We document CVE-2019-17571/

Where is this CVE tonnage?

Gary

On Thu, Dec 23, 2021 at 10:39 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> Volkan>To the best of
> Volkan>my knowledge, nobody has reached out to us with such a request
> except you
> Volkan>and Leo
>
> I think they just swallowed the pill that "1.x is marked EOL", and they did
> workarounds.
> a) make security team understand "the CVEs of 1.x are not that impactful
> for them"
> b) make internal forks that cut the problematic classes
> c) RedHat having their own fork
>
> However, now log4j went on the radars again,
> so I believe it is way easier (and better) to **fix** CVE than to keep
> explaining that
> "CVEs are not important in this specific case"
>
> I believe you might have access to the download stats for log4j.jar, so you
> can
> relate on the number of its usages.
>
> However, now I realize that the project itself is NOT dead as long as there
> are
> people that want to maintain it.
> It is not wise to say "log4j 1.x is dead" or "log4j 1.x is EOL" when there
> are people
> willing to maintain and release new versions.
> Note: I am not that crazy to do major refactorings in 1.x branch.
>
> So I figured out that releasing log4j 18+ ( : ) would make the lives of
> MANY MANY
> engineers and apps way easier. They would have a drop-in-replacement that
> fixes CVEs,
> improves security all over the world, and so on.
>
> Volkan>I bet it is a matter of months people will start asking for
> Volkan>other fixes once we make a 1.x release.
>
> Now we have a real issue: 1.x has LOTs of known CVEs.
> Could we refrain from theoretical discussions?
>
> Just in case, if in February you observe 10 newly created PRs,
> then it would be a nice problem to have.
>
> If all the PRs turn out to be trivial (e.g. fix NPE in a special case, or
> fix java.version parsing for Java 17),
> then you could just merge them and release 1.2.19
>
> If the review would take noticeable time, you could just say:
> "sorry, I have no time for reviewing the change, please consider creating a
> new PMC for log4j 1.x".
>
> **everybody's** time is limited. If you have no time or desire to
> maintain/support/review/release 1.x,
> then just ask the others do to that (e.g. invite new people to PMC or give
> away 1.x to another PMC).
>
> It might be there will be 10PRs, and there will be *noone* willing to
> review and nobody willing to inherit 1.x
> Then the PRs would be just abandoned.
>
> For instance, the current LOG4J2 JIRA has 809 issues. I doubt you will ever
> fix all of them :)
> So I doubt the question of "what do you do with old issues" or "what if
> there are 100500 open PRs"
> add any value.
>
> WDYT?
>
> Vladimir
>

Re: Resurrecting log4j 1.x

[Vladimir Sitnikov]

> I think we will try to meet once or twice a month primarily to
>reduce that backlog.

If you ever figure out the solution, please tweet or blog on that (or at
least mention me).
I think ANY successful project ends up in 100500 open issues.

For instance:
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
https://github.com/gradle/gradle/issues 1900 open, 7000 closed
...

I do not blame you. I just mention you cant fix all the issues for
everybody.
However, it is fair to accept contributions when they solve real issues.

Vladimir

Re: Resurrecting log4j 1.x

[Ralph Goers]

> On Dec 23, 2021, at 8:38 AM, Vladimir Sitnikov  
> wrote:
> 
> 
> For instance, the current LOG4J2 JIRA has 809 issues. I doubt you will ever
> fix all of them :)

Actually, in the midst of working on the CVEs we discussed this. We have found 
that Slack 
calls work really well for us so I think we will try to meet once or twice a 
month primarily to 
reduce that backlog.

Ralph

Re: Resurrecting log4j 1.x

[Vladimir Sitnikov]

Volkan>To the best of
Volkan>my knowledge, nobody has reached out to us with such a request
except you
Volkan>and Leo

I think they just swallowed the pill that "1.x is marked EOL", and they did
workarounds.
a) make security team understand "the CVEs of 1.x are not that impactful
for them"
b) make internal forks that cut the problematic classes
c) RedHat having their own fork

However, now log4j went on the radars again,
so I believe it is way easier (and better) to **fix** CVE than to keep
explaining that
"CVEs are not important in this specific case"

I believe you might have access to the download stats for log4j.jar, so you
can
relate on the number of its usages.

However, now I realize that the project itself is NOT dead as long as there
are
people that want to maintain it.
It is not wise to say "log4j 1.x is dead" or "log4j 1.x is EOL" when there
are people
willing to maintain and release new versions.
Note: I am not that crazy to do major refactorings in 1.x branch.

So I figured out that releasing log4j 18+ ( : ) would make the lives of
MANY MANY
engineers and apps way easier. They would have a drop-in-replacement that
fixes CVEs,
improves security all over the world, and so on.

Volkan>I bet it is a matter of months people will start asking for
Volkan>other fixes once we make a 1.x release.

Now we have a real issue: 1.x has LOTs of known CVEs.
Could we refrain from theoretical discussions?

Just in case, if in February you observe 10 newly created PRs,
then it would be a nice problem to have.

If all the PRs turn out to be trivial (e.g. fix NPE in a special case, or
fix java.version parsing for Java 17),
then you could just merge them and release 1.2.19

If the review would take noticeable time, you could just say:
"sorry, I have no time for reviewing the change, please consider creating a
new PMC for log4j 1.x".

**everybody's** time is limited. If you have no time or desire to
maintain/support/review/release 1.x,
then just ask the others do to that (e.g. invite new people to PMC or give
away 1.x to another PMC).

It might be there will be 10PRs, and there will be *noone* willing to
review and nobody willing to inherit 1.x
Then the PRs would be just abandoned.

For instance, the current LOG4J2 JIRA has 809 issues. I doubt you will ever
fix all of them :)
So I doubt the question of "what do you do with old issues" or "what if
there are 100500 open PRs"
add any value.

WDYT?

Vladimir

Re: Resurrecting log4j 1.x

[Volkan Yazıcı]

Vladimir, mind helping us to quantify this "need", please? To the best of
my knowledge, nobody has reached out to us with such a request except you
and Leo. Is it a gut feeling that is the basis of your justification or is
there an explicit demand from the community that I am missing? I also did
not see any users chiming in your voting thread. You have shared some other
Log4j 1.x forks in the wild. Are these used widely?

It would be unfair to claim that the PMC is hesitant to move forward with a
simple git setup plus some fix backports, the concern is much deeper than
this. Not to mention the extra maintenance cost it will put on the
shoulders of our limited development resources. (I know you've volunteered
for maintenance, but as you also very well know, we all will be
responsible.) I bet it is a matter of months people will start asking for
other fixes once we make a 1.x release. The uncertainty about the project
communicated will be massive and irrevertible.

On Mon, Dec 20, 2021 at 3:06 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> Ron,
>
> There's a need to move log4j 1.x forward, and Ralph Goers suggested
> that the way to go is to re-incubate it, see [1].
>
> Could you sponsor the project or do you want Incubator to do that? (see
> [2])
>
> [1]: https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5
> [2]: https://lists.apache.org/thread/c2362g4m4m4y1n7zl444ncvhmfb9oy0m
>
> Vladimir
>

Re: Resurrecting log4j 1.x

[Ralph Goers]

Note that this “requires access to the logging configuration” is simply wrong. 
I wish I had 
known 10 years ago what I now know about JNDI, and Java’s LDAP support via 
JNDI. 
Unfortunately, I only learned about it in the last 3 weeks.

The LDAP schema for Java is where the real problem lies. It defines data to 
instantiate 
classes that implement the Referenceable interface. These classes are created 
via an 
ObjectFactory. The wonderful thing about the Java schema. Is that it defines 
referenece 
address attributes, which is the location of where you can find the object 
factory class object.

So if have access to LDAP you can manipulate the data to point to your own 
ObjectFactory. 
So long as that returns whatever the caller was expecting you can do whatever 
else you 
want completely undetected. Or if you have access to wherever the objects 
reside you can 
replace them there with a custom class.

Of course, Java also supports Serializable objects via LDAP and everyone knows 
that has 
holes like Swiss cheese.

So if you have an existing configuration that already accesses LDAP via JNDI to 
get a 
password no one needs to touch the config file to perform an RCE.  

This is the perfect way for an unhappy employee to create a backdoor.

Ralph



> On Dec 21, 2021, at 11:12 AM, Leo Simons  wrote:
> 
> On Tue, 21 Dec 2021 at 18:48, Gary Gregory  wrote:
> 
>> …
>> I wonder what logback actually means by "Temporarily removed DB support for
>> security reasons.", did they remove public or protected code? Well we have
>> enough to deal with here without worrying about that.
> 
> 
> Yeah they deleted DBAppender. Public code that you can/should reference in
> a config file. So source/binary/config incompatible.
> 
> https://github.com/qos-ch/logback/commit/87291079a1de9369ac67e20dc70a8fdc7cc4359c
> 
> So logback 1.2.8 has it, 1.2.9 doesn’t, 1.3 (JDK8+) will probably get a
> security hardened version, probably then backported to make a 1.2.10 for
> JDK7.
> 
> (Of course a very different project, different vulnerability, etc, so
> different considerations & choices)
> 
> Spring is picking it up in their release:
> 
> https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot
> 
> So Twitter after Christmas will start to teach us about user response :-)
> 
> 
> Cheers,
> 
> 
> Leo

Re: Resurrecting log4j 1.x

[Leo Simons]

On Tue, 21 Dec 2021 at 18:48, Gary Gregory  wrote:

> …
> I wonder what logback actually means by "Temporarily removed DB support for
> security reasons.", did they remove public or protected code? Well we have
> enough to deal with here without worrying about that.


Yeah they deleted DBAppender. Public code that you can/should reference in
a config file. So source/binary/config incompatible.

https://github.com/qos-ch/logback/commit/87291079a1de9369ac67e20dc70a8fdc7cc4359c

So logback 1.2.8 has it, 1.2.9 doesn’t, 1.3 (JDK8+) will probably get a
security hardened version, probably then backported to make a 1.2.10 for
JDK7.

(Of course a very different project, different vulnerability, etc, so
different considerations & choices)

Spring is picking it up in their release:

https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot

So Twitter after Christmas will start to teach us about user response :-)


Cheers,


Leo

Re: Resurrecting log4j 1.x

[Gary Gregory]

WRT naming, let's stay with considering a 1.2.18, that's the type of naming
we used in 2.x with 2.12.x and 2.3.x, no need to make things more
complicated IMO.

I wonder what logback actually means by "Temporarily removed DB support for
security reasons.", did they remove public or protected code? Well we have
enough to deal with here without worrying about that.

Gary

On Tue, Dec 21, 2021, 12:05 Leo Simons  wrote:

> (On mobile, excuse typos/top post)
>
> +1. My interest is in staying here, work together, make a security release
> as one community (and I probably will be gone when security is no longer a
> topic), that is as good as possible, out soon(tm). I won’t object to but
> also won’t join something “new” (feel free to use any code I wrote of
> course).
>
> PMC is supportive but busy with 2.x. Focus on 2.x is right. Cool there is a
> 2.3 patch coming. Learn anything relevant to 1.x? When 2.x security worries
> die down, there is time for 1.x security worries (after seasonal holidays
> too, I hope!). All this was said. Asking for some patience is
> understandable. As contributors we can prepare the code in parallel, maybe
> host an RC somewhere to get testing done, write security/migration docs. I
> ran out of time, not out of work that could progress.
>
> I think involving incubator is wrong. Subproject process at incubator is
> for IP clearance which is not needed here. Starting a new TLP for log4j 1
> is confusing, lot of work, not needed. Let’s work together here. (I was on
> incubator PMC many years, started and retired couple projects too.)
>
> Grateful for critical review and attention from committers. Feedback should
> be considered. For example did you know Gary worked on 1.x way back when,
> and has also maintained a bunch of other ex-Jakarta stuff for years and
> years? (like 20?) Meritocracy means his word has weight, but more important
> - experience means his feedback is worth gold.
>
> How to balance quality of solution with timeliness&effort? Logback dropped
> DB support temporarily (
> https://logback.qos.ch/news.html ). Difficult judgements to make. Don’t
> have to agree on all details. Ultimately “code talks”, make something
> “obviously” better than 1.2 and we will have agreement enough. Take some
> time to explore the friction to find the best outcome we can. (Deleting
> log4j.net and making a JDK 11 release can be done by everyone on GitHub,
> I’m convinced the Apache community can contribute something better, curious
> how much better.)
>
> Having the conversations is how we find the best approach. Back in
> 2004/2005 I worked on gump as a way to keep backward compatibility in core
> libraries like ant,xerces,log4j, it has been educational for me to argue
> the other direction now for once…I am normally not the “move faster” guy…
> and it’s even for the same bloody code… :-).
>
> With (an evolution of) the second PR I started, naming wise we could go for
> “1.2.17.1”, making the “security only” part extra clear.
>
>
> Cheers!
>
>
> Leo
>
> On Tue, 21 Dec 2021 at 15:18, Ralph Goers 
> wrote:
>
> > To be clear, we have declared Java 6 & 7 EOL for Log4j 2. Yet we are here
> > building
> > patch releases for them. We are only including the security patches. I
> see
> > Log4j 1.x
> > as exactly the same as those.
> >
> > Ralph
> >
> > > On Dec 21, 2021, at 6:45 AM, Gary Gregory 
> > wrote:
> > >
> > > I agree with Remko on all his points.
> > >
> > > As I've stated before, IF there is a 1.2.18, it should ONLY be for
> CVEs,
> > > and where applicable, fixed in the same style as we have for 2.x. This
> > is,
> > > IMO, what would be best for users *short* of migrating for 2.x.
> > >
> > > A problem from my perspective will be users thinking the project is
> > > resurrected and asking for "just this little fix" or "just that little
> > > feature", which would be a "no" from me.
> > >
> > > We have a 1.2 compatibility layer in 2.x, let's make that better so
> that
> > > 2.x could become as close as possible to a drop-in replacement for 1.2.
> > >
> > > Gary
> > >
> > >
> > > On Tue, Dec 21, 2021 at 8:36 AM Remko Popma 
> > wrote:
> > >
> > >> Vladimir,
> > >>
> > >> Have you had a chance to work on a patch for the security
> > vulnerabilities?
> > >>
> > >> While there is understandably not much interest in “resurrecting” the
> > >> Log4j 1.x project, overall people are positive about releasing a
> 1.2.18
> > >> with security patches.
> > >>
> > >> I think it would be most helpful if we can stay focused on those
> > security
> > >> patches rather than pushing the PMC for an effort to revive an EOL
> > project.
> > >>
> > >> I can see how things appear to be moving very slowly from your
> > >> perspective, but as Ralph pointed out the PMC is pretty busy with 2.x
> > patch
> > >> releases and the flood of email that has been piling up.
> > >>
> > >> I see your enthusiasm and eagerness to contribute and that’s really
> > great!
> > >> I would suggest that you direct that energy towards lo

Re: Resurrecting log4j 1.x

[Leo Simons]

(On mobile, excuse typos/top post)

+1. My interest is in staying here, work together, make a security release
as one community (and I probably will be gone when security is no longer a
topic), that is as good as possible, out soon(tm). I won’t object to but
also won’t join something “new” (feel free to use any code I wrote of
course).

PMC is supportive but busy with 2.x. Focus on 2.x is right. Cool there is a
2.3 patch coming. Learn anything relevant to 1.x? When 2.x security worries
die down, there is time for 1.x security worries (after seasonal holidays
too, I hope!). All this was said. Asking for some patience is
understandable. As contributors we can prepare the code in parallel, maybe
host an RC somewhere to get testing done, write security/migration docs. I
ran out of time, not out of work that could progress.

I think involving incubator is wrong. Subproject process at incubator is
for IP clearance which is not needed here. Starting a new TLP for log4j 1
is confusing, lot of work, not needed. Let’s work together here. (I was on
incubator PMC many years, started and retired couple projects too.)

Grateful for critical review and attention from committers. Feedback should
be considered. For example did you know Gary worked on 1.x way back when,
and has also maintained a bunch of other ex-Jakarta stuff for years and
years? (like 20?) Meritocracy means his word has weight, but more important
- experience means his feedback is worth gold.

How to balance quality of solution with timeliness&effort? Logback dropped
DB support temporarily (
https://logback.qos.ch/news.html ). Difficult judgements to make. Don’t
have to agree on all details. Ultimately “code talks”, make something
“obviously” better than 1.2 and we will have agreement enough. Take some
time to explore the friction to find the best outcome we can. (Deleting
log4j.net and making a JDK 11 release can be done by everyone on GitHub,
I’m convinced the Apache community can contribute something better, curious
how much better.)

Having the conversations is how we find the best approach. Back in
2004/2005 I worked on gump as a way to keep backward compatibility in core
libraries like ant,xerces,log4j, it has been educational for me to argue
the other direction now for once…I am normally not the “move faster” guy…
and it’s even for the same bloody code… :-).

With (an evolution of) the second PR I started, naming wise we could go for
“1.2.17.1”, making the “security only” part extra clear.


Cheers!


Leo

On Tue, 21 Dec 2021 at 15:18, Ralph Goers 
wrote:

> To be clear, we have declared Java 6 & 7 EOL for Log4j 2. Yet we are here
> building
> patch releases for them. We are only including the security patches. I see
> Log4j 1.x
> as exactly the same as those.
>
> Ralph
>
> > On Dec 21, 2021, at 6:45 AM, Gary Gregory 
> wrote:
> >
> > I agree with Remko on all his points.
> >
> > As I've stated before, IF there is a 1.2.18, it should ONLY be for CVEs,
> > and where applicable, fixed in the same style as we have for 2.x. This
> is,
> > IMO, what would be best for users *short* of migrating for 2.x.
> >
> > A problem from my perspective will be users thinking the project is
> > resurrected and asking for "just this little fix" or "just that little
> > feature", which would be a "no" from me.
> >
> > We have a 1.2 compatibility layer in 2.x, let's make that better so that
> > 2.x could become as close as possible to a drop-in replacement for 1.2.
> >
> > Gary
> >
> >
> > On Tue, Dec 21, 2021 at 8:36 AM Remko Popma 
> wrote:
> >
> >> Vladimir,
> >>
> >> Have you had a chance to work on a patch for the security
> vulnerabilities?
> >>
> >> While there is understandably not much interest in “resurrecting” the
> >> Log4j 1.x project, overall people are positive about releasing a 1.2.18
> >> with security patches.
> >>
> >> I think it would be most helpful if we can stay focused on those
> security
> >> patches rather than pushing the PMC for an effort to revive an EOL
> project.
> >>
> >> I can see how things appear to be moving very slowly from your
> >> perspective, but as Ralph pointed out the PMC is pretty busy with 2.x
> patch
> >> releases and the flood of email that has been piling up.
> >>
> >> I see your enthusiasm and eagerness to contribute and that’s really
> great!
> >> I would suggest that you direct that energy towards looking at the Log4j
> >> 1.x source code, figuring out what classes should be modified in which
> way,
> >> and how to test those changes.
> >> And discussing such code changes on the mailing list together with
> fellow
> >> enthusiasts.
> >>
> >> Migration to git will happen. Maybe not as fast as you would like, but
> >> please cut the PMC some slack in this stressful time.
> >>
> >> Surely you can start working on the actual security improvements without
> >> re-incubating a Log4j 1.x project, in parallel with (while waiting for)
> the
> >> migration from svn to git?
> >>
> >> Onwards,
> >>
> >> Remko
> >>
> >>
> >>> On De

Re: Resurrecting log4j 1.x

[Ralph Goers]

To be clear, we have declared Java 6 & 7 EOL for Log4j 2. Yet we are here 
building 
patch releases for them. We are only including the security patches. I see 
Log4j 1.x 
as exactly the same as those.

Ralph

> On Dec 21, 2021, at 6:45 AM, Gary Gregory  wrote:
> 
> I agree with Remko on all his points.
> 
> As I've stated before, IF there is a 1.2.18, it should ONLY be for CVEs,
> and where applicable, fixed in the same style as we have for 2.x. This is,
> IMO, what would be best for users *short* of migrating for 2.x.
> 
> A problem from my perspective will be users thinking the project is
> resurrected and asking for "just this little fix" or "just that little
> feature", which would be a "no" from me.
> 
> We have a 1.2 compatibility layer in 2.x, let's make that better so that
> 2.x could become as close as possible to a drop-in replacement for 1.2.
> 
> Gary
> 
> 
> On Tue, Dec 21, 2021 at 8:36 AM Remko Popma  wrote:
> 
>> Vladimir,
>> 
>> Have you had a chance to work on a patch for the security vulnerabilities?
>> 
>> While there is understandably not much interest in “resurrecting” the
>> Log4j 1.x project, overall people are positive about releasing a 1.2.18
>> with security patches.
>> 
>> I think it would be most helpful if we can stay focused on those security
>> patches rather than pushing the PMC for an effort to revive an EOL project.
>> 
>> I can see how things appear to be moving very slowly from your
>> perspective, but as Ralph pointed out the PMC is pretty busy with 2.x patch
>> releases and the flood of email that has been piling up.
>> 
>> I see your enthusiasm and eagerness to contribute and that’s really great!
>> I would suggest that you direct that energy towards looking at the Log4j
>> 1.x source code, figuring out what classes should be modified in which way,
>> and how to test those changes.
>> And discussing such code changes on the mailing list together with fellow
>> enthusiasts.
>> 
>> Migration to git will happen. Maybe not as fast as you would like, but
>> please cut the PMC some slack in this stressful time.
>> 
>> Surely you can start working on the actual security improvements without
>> re-incubating a Log4j 1.x project, in parallel with (while waiting for) the
>> migration from svn to git?
>> 
>> Onwards,
>> 
>> Remko
>> 
>> 
>>> On Dec 21, 2021, at 20:52, Vladimir Sitnikov <
>> sitnikov.vladi...@gmail.com> wrote:
>>> 
>>> Ron,
>>> 
>>> I know these are not easy times for you,
>>> however, it looks like we are going in circles.
>>> 
>>> There's visible demand for releasing fixes for 1.x:
>>> https://lists.apache.org/thread/llgp7b9v1t081o3215o7xq4zpct1x0b4
>>> 
>>> So the question is
>>> "Could you sponsor the project or do you want Incubator to do that?"
>>> 
>>> I see the current crew is not interested in fixing and releasing 1.x.
>>> Why don't you just allow others to fix things?
>>> 
>>> Vladimir
>> 

Re: Resurrecting log4j 1.x

[Gary Gregory]

I agree with Remko on all his points.

As I've stated before, IF there is a 1.2.18, it should ONLY be for CVEs,
and where applicable, fixed in the same style as we have for 2.x. This is,
IMO, what would be best for users *short* of migrating for 2.x.

A problem from my perspective will be users thinking the project is
resurrected and asking for "just this little fix" or "just that little
feature", which would be a "no" from me.

We have a 1.2 compatibility layer in 2.x, let's make that better so that
2.x could become as close as possible to a drop-in replacement for 1.2.

Gary


On Tue, Dec 21, 2021 at 8:36 AM Remko Popma  wrote:

> Vladimir,
>
> Have you had a chance to work on a patch for the security vulnerabilities?
>
> While there is understandably not much interest in “resurrecting” the
> Log4j 1.x project, overall people are positive about releasing a 1.2.18
> with security patches.
>
> I think it would be most helpful if we can stay focused on those security
> patches rather than pushing the PMC for an effort to revive an EOL project.
>
> I can see how things appear to be moving very slowly from your
> perspective, but as Ralph pointed out the PMC is pretty busy with 2.x patch
> releases and the flood of email that has been piling up.
>
> I see your enthusiasm and eagerness to contribute and that’s really great!
> I would suggest that you direct that energy towards looking at the Log4j
> 1.x source code, figuring out what classes should be modified in which way,
> and how to test those changes.
> And discussing such code changes on the mailing list together with fellow
> enthusiasts.
>
> Migration to git will happen. Maybe not as fast as you would like, but
> please cut the PMC some slack in this stressful time.
>
> Surely you can start working on the actual security improvements without
> re-incubating a Log4j 1.x project, in parallel with (while waiting for) the
> migration from svn to git?
>
> Onwards,
>
> Remko
>
>
> > On Dec 21, 2021, at 20:52, Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote:
> >
> > Ron,
> >
> > I know these are not easy times for you,
> > however, it looks like we are going in circles.
> >
> > There's visible demand for releasing fixes for 1.x:
> > https://lists.apache.org/thread/llgp7b9v1t081o3215o7xq4zpct1x0b4
> >
> > So the question is
> > "Could you sponsor the project or do you want Incubator to do that?"
> >
> > I see the current crew is not interested in fixing and releasing 1.x.
> > Why don't you just allow others to fix things?
> >
> > Vladimir
>

Re: Resurrecting log4j 1.x

[Remko Popma]

Vladimir,

Have you had a chance to work on a patch for the security vulnerabilities?

While there is understandably not much interest in “resurrecting” the Log4j 1.x 
project, overall people are positive about releasing a 1.2.18 with security 
patches. 

I think it would be most helpful if we can stay focused on those security 
patches rather than pushing the PMC for an effort to revive an EOL project. 

I can see how things appear to be moving very slowly from your perspective, but 
as Ralph pointed out the PMC is pretty busy with 2.x patch releases and the 
flood of email that has been piling up. 

I see your enthusiasm and eagerness to contribute and that’s really great! I 
would suggest that you direct that energy towards looking at the Log4j 1.x 
source code, figuring out what classes should be modified in which way, and how 
to test those changes. 
And discussing such code changes on the mailing list together with fellow 
enthusiasts. 

Migration to git will happen. Maybe not as fast as you would like, but please 
cut the PMC some slack in this stressful time. 

Surely you can start working on the actual security improvements without 
re-incubating a Log4j 1.x project, in parallel with (while waiting for) the 
migration from svn to git? 

Onwards,

Remko


> On Dec 21, 2021, at 20:52, Vladimir Sitnikov  
> wrote:
> 
> Ron,
> 
> I know these are not easy times for you,
> however, it looks like we are going in circles.
> 
> There's visible demand for releasing fixes for 1.x:
> https://lists.apache.org/thread/llgp7b9v1t081o3215o7xq4zpct1x0b4
> 
> So the question is
> "Could you sponsor the project or do you want Incubator to do that?"
> 
> I see the current crew is not interested in fixing and releasing 1.x.
> Why don't you just allow others to fix things?
> 
> Vladimir

Re: Resurrecting log4j 1.x

[Vladimir Sitnikov]

Ron,

I know these are not easy times for you,
however, it looks like we are going in circles.

There's visible demand for releasing fixes for 1.x:
https://lists.apache.org/thread/llgp7b9v1t081o3215o7xq4zpct1x0b4

So the question is
"Could you sponsor the project or do you want Incubator to do that?"

I see the current crew is not interested in fixing and releasing 1.x.
Why don't you just allow others to fix things?

Vladimir

Re: Resurrecting log4j 1.x

[Gary Gregory]

Is https://github.com/apache/log4j a mirror of an SVN repo?

Gary

On Mon, Dec 20, 2021 at 2:31 PM Carter Kozak  wrote:
>
> Same, git migration makes sense to me if we are fixing CVEs.
>
> -ck
>
> > On Dec 20, 2021, at 14:28, Matt Sicker  wrote:
> >
> > Sorry, I forgot to vote explicitly. I'd be +1 on the git repo
> > migration, but I was also iffy on enabling issues there.
> >
> >> On Mon, Dec 20, 2021 at 1:23 PM Vladimir Sitnikov
> >>  wrote:
> >>
> >> Ralph>I have no problem doing stuff on GitHub
> >>
> >> Bingo!
> >> That is what I said earlier.
> >>
> >> It is really really demotivating that "PMC is not against".
> >> I suggested the move. Neither Ralph nor Matt welcomed the change with +1.
> >>
> >> At no time do I request you to perform the Git migration.
> >> At no time do I request you to refactor the build scripts.
> >> Yet you do ask A LOT before you even try doing something.
> >>
> >> That is exactly the reason I believe it is way less time consuming for all
> >> the parties to re-incubate 1.x
> >> rather than keep all those "But someone needs to migrate".
> >>
> >> Ralph>But someone needs to migrate it from SVN and I don’t have the time
> >> for that
> >>
> >> I can do that just fine. Would you just approve the move?
> >> Is it really that hard to respond with +1 on move to Git thread?
> >> What I get is -1(binding), and irrelevant comments like "someone needs to
> >> migrate".
> >> Thank you. I know someone needs to do that.
> >>
> >> The Git repository with the full log4j 1.x history already exists.
> >> I highlighted it on a "[VOTE] Move log4j 1.x from SVN to Git" thread:
> >> https://lists.apache.org/thread/0z34x9536mtr2z98m4s4dpqglzvjhjfq
> >>
> >> Vladimir
>

Re: Resurrecting log4j 1.x

[Carter Kozak]

Same, git migration makes sense to me if we are fixing CVEs.

-ck

> On Dec 20, 2021, at 14:28, Matt Sicker  wrote:
> 
> Sorry, I forgot to vote explicitly. I'd be +1 on the git repo
> migration, but I was also iffy on enabling issues there.
> 
>> On Mon, Dec 20, 2021 at 1:23 PM Vladimir Sitnikov
>>  wrote:
>> 
>> Ralph>I have no problem doing stuff on GitHub
>> 
>> Bingo!
>> That is what I said earlier.
>> 
>> It is really really demotivating that "PMC is not against".
>> I suggested the move. Neither Ralph nor Matt welcomed the change with +1.
>> 
>> At no time do I request you to perform the Git migration.
>> At no time do I request you to refactor the build scripts.
>> Yet you do ask A LOT before you even try doing something.
>> 
>> That is exactly the reason I believe it is way less time consuming for all
>> the parties to re-incubate 1.x
>> rather than keep all those "But someone needs to migrate".
>> 
>> Ralph>But someone needs to migrate it from SVN and I don’t have the time
>> for that
>> 
>> I can do that just fine. Would you just approve the move?
>> Is it really that hard to respond with +1 on move to Git thread?
>> What I get is -1(binding), and irrelevant comments like "someone needs to
>> migrate".
>> Thank you. I know someone needs to do that.
>> 
>> The Git repository with the full log4j 1.x history already exists.
>> I highlighted it on a "[VOTE] Move log4j 1.x from SVN to Git" thread:
>> https://lists.apache.org/thread/0z34x9536mtr2z98m4s4dpqglzvjhjfq
>> 
>> Vladimir

Re: Resurrecting log4j 1.x

[Matt Sicker]

Sorry, I forgot to vote explicitly. I'd be +1 on the git repo
migration, but I was also iffy on enabling issues there.

On Mon, Dec 20, 2021 at 1:23 PM Vladimir Sitnikov
 wrote:
>
> Ralph>I have no problem doing stuff on GitHub
>
> Bingo!
> That is what I said earlier.
>
> It is really really demotivating that "PMC is not against".
> I suggested the move. Neither Ralph nor Matt welcomed the change with +1.
>
> At no time do I request you to perform the Git migration.
> At no time do I request you to refactor the build scripts.
> Yet you do ask A LOT before you even try doing something.
>
> That is exactly the reason I believe it is way less time consuming for all
> the parties to re-incubate 1.x
> rather than keep all those "But someone needs to migrate".
>
> Ralph>But someone needs to migrate it from SVN and I don’t have the time
> for that
>
> I can do that just fine. Would you just approve the move?
> Is it really that hard to respond with +1 on move to Git thread?
> What I get is -1(binding), and irrelevant comments like "someone needs to
> migrate".
> Thank you. I know someone needs to do that.
>
> The Git repository with the full log4j 1.x history already exists.
> I highlighted it on a "[VOTE] Move log4j 1.x from SVN to Git" thread:
> https://lists.apache.org/thread/0z34x9536mtr2z98m4s4dpqglzvjhjfq
>
> Vladimir

Re: Resurrecting log4j 1.x

[Vladimir Sitnikov]

Ralph>I have no problem doing stuff on GitHub

Bingo!
That is what I said earlier.

It is really really demotivating that "PMC is not against".
I suggested the move. Neither Ralph nor Matt welcomed the change with +1.

At no time do I request you to perform the Git migration.
At no time do I request you to refactor the build scripts.
Yet you do ask A LOT before you even try doing something.

That is exactly the reason I believe it is way less time consuming for all
the parties to re-incubate 1.x
rather than keep all those "But someone needs to migrate".

Ralph>But someone needs to migrate it from SVN and I don’t have the time
for that

I can do that just fine. Would you just approve the move?
Is it really that hard to respond with +1 on move to Git thread?
What I get is -1(binding), and irrelevant comments like "someone needs to
migrate".
Thank you. I know someone needs to do that.

The Git repository with the full log4j 1.x history already exists.
I highlighted it on a "[VOTE] Move log4j 1.x from SVN to Git" thread:
https://lists.apache.org/thread/0z34x9536mtr2z98m4s4dpqglzvjhjfq

Vladimir

Re: Resurrecting log4j 1.x

[Ralph Goers]

I have no problem doing stuff on GitHub. Creating a repo is easy. But someone 
needs to migrate it from SVN and I don’t have the time for that. If someone 
puts up a repo at GitHub with all the history I’d be happy to create it under 
the logging project.

Ralph



> On Dec 20, 2021, at 12:08 PM, Vladimir Sitnikov  
> wrote:
> 
> Matt>I'm not against applying patches to the svn repo, either.
> 
> How about pull requests at GitHub?
> 
> Vladimir

Re: Resurrecting log4j 1.x

[Vladimir Sitnikov]

Matt>I'm not against applying patches to the svn repo, either.

How about pull requests at GitHub?

Vladimir

Re: Resurrecting log4j 1.x

[Matt Sicker]

I'm not against applying patches to the svn repo, either. I haven't
forgotten how to use svn as I still use it for Secretary stuff (plus
where we put release artifacts). Given that a PMC member would need to
do part of the release anyways, that hopefully isn't a blocker.

I'm +1 for making a minimal 1.2.18 release to address CVEs. If there
are any major bugs that have a simple fix, those might also qualify,
but I wouldn't recommend spending much time there. Log4j 1.x has some
intractable bugs that were only fixed in subsequent projects like
Log4j 2.x and Logback.

On Mon, Dec 20, 2021 at 12:39 PM Andrii Berezovskyi  wrote:
>
> Dear Vladimir,
>
> > When it comes to code-related changes, the reviews are vague, and it is
> > really hard (impossible?) to find consensus.
> I somehow got an idea that ripping out classes that could lead to a 
> NoClassDefFoundError for existing users did not fit the definition of "binary 
> compability" for the log4j2 committers. As much as I would love to rip the 
> classes in question out, I must admit that doing so is not binary compatible.
>
> And if I recall correctly, the request on 
> https://github.com/apache/log4j/pull/17 was to separate build changes from 
> the code fixes and start with a PR to fix one CVE only (and have that fix to 
> be something else than removing a class) so that can be reviewed in 
> reasonable time. And if I read between the lines well, the committers wanted 
> to see viable PRs before doing infra work that you are (correctly) 
> suggesting. But apologies for butting in if I got something wrong.
>
> Best regards,
> Andrew

Re: Resurrecting log4j 1.x

[Andrii Berezovskyi]

Dear Vladimir,

> When it comes to code-related changes, the reviews are vague, and it is
> really hard (impossible?) to find consensus.
I somehow got an idea that ripping out classes that could lead to a 
NoClassDefFoundError for existing users did not fit the definition of "binary 
compability" for the log4j2 committers. As much as I would love to rip the 
classes in question out, I must admit that doing so is not binary compatible.

And if I recall correctly, the request on 
https://github.com/apache/log4j/pull/17 was to separate build changes from the 
code fixes and start with a PR to fix one CVE only (and have that fix to be 
something else than removing a class) so that can be reviewed in reasonable 
time. And if I read between the lines well, the committers wanted to see viable 
PRs before doing infra work that you are (correctly) suggesting. But apologies 
for butting in if I got something wrong.

Best regards,
Andrew

Re: Resurrecting log4j 1.x

[Ralph Goers]

Vladimir,

The PMC is totally focused on resolving issues for log4j 2 at the moment. We 
are still getting tons
of emails you can’t see. So if it seems like we are being unhelpful it is 
entirely because we are 
focused on that.

We’ve stated several times that we don’t think resurrecting Log4j 1.x 
permanently is a good idea. 
Besides the vulnerabilities the code has serious threading issues that cannot 
be fixed with Log4j 1’s 
architecture. While I wasn’t on the Logging Services PMC when discussions about 
what to do 
were going on I read the email threads. There were many discussions about 
breaking compatibility 
that no one wanted to do, which is ultimately how SLF4J and Logback came into 
existence. 
If you are interested in that sort of thing you can go read to log4j dev list 
from 15 years or so ago. 

By the time I joined the Logging Services PMC most log4j 1.x development had 
stopped. Some 
of the contributors were still around but no one was doing much of anything.

The point of this is that we aren’t against fixing the CVEs in Log4j 1, but not 
by having stuff fail 
because the class is no longer there. JNDI can be scaled down as we have done 
in Log4j 2. The 
log server could prevent deserialization of unknown or arbitrary classes. Etc.

Ralph


> On Dec 20, 2021, at 10:59 AM, Vladimir Sitnikov  
> wrote:
> 
> Ron>wouldn't a more efficient approach be to offer support to
> Ron>Logging Services
> 
> Ron,
> I did try my best to offer my help with updating log4j 1.x.
> Unfortunately, I failed and none of Logging Services PMC accepted it.
> Here are the facts:
> https://lists.apache.org/thread/6lhkyytvpg4md757tfydb1k0mmp5j1oc
> 
> Ron>Re-starting the entire EOL'ed Log4j1
> Ron>engine with a new crew to fix one issue is confusing
> 
> It is confusing for me as well, however, the current crew does seem to
> cooperate
> regarding the changes to 1.x.
> 
> Ron>I don't get the sense folks are against fixing things
> 
> 1) There are multiple known open CVEs in log4j 1.x. The team is not really
> fixing known security issues.
> 2) All the responses from the current PMC are behind the lines of
> "evangelizing 2.x"
> rather than suggesting a way to fix 1.x and release it.
> 
> Ron>To answer your
> Ron>question about sponsorship, I want to explore partnering with Logging
> Ron>Services before forming a new Log4j1 team.
> 
> For example, my very basic suggestion was "let's move 1.x to Git for easier
> contribution",
> however, none of the PMC members approved the change.
> 
> When it comes to code-related changes, the reviews are vague, and it is
> really hard (impossible?) to find consensus.
> On top of that, the review is complicated by the fact that **multiple**
> fixes are needed for log4j 1.x
> 1) There are multiple known CVEs regarding 1.x
> 2) 1.x uses a really old build system, so, in my opinion, the build scripts
> should be updated before any other changes
> 
> Vladimir

Re: Resurrecting log4j 1.x

[Vladimir Sitnikov]

Ron>wouldn't a more efficient approach be to offer support to
Ron>Logging Services

Ron,
I did try my best to offer my help with updating log4j 1.x.
Unfortunately, I failed and none of Logging Services PMC accepted it.
Here are the facts:
https://lists.apache.org/thread/6lhkyytvpg4md757tfydb1k0mmp5j1oc

Ron>Re-starting the entire EOL'ed Log4j1
Ron>engine with a new crew to fix one issue is confusing

It is confusing for me as well, however, the current crew does seem to
cooperate
regarding the changes to 1.x.

Ron>I don't get the sense folks are against fixing things

1) There are multiple known open CVEs in log4j 1.x. The team is not really
fixing known security issues.
2) All the responses from the current PMC are behind the lines of
"evangelizing 2.x"
rather than suggesting a way to fix 1.x and release it.

Ron>To answer your
Ron>question about sponsorship, I want to explore partnering with Logging
Ron>Services before forming a new Log4j1 team.

For example, my very basic suggestion was "let's move 1.x to Git for easier
contribution",
however, none of the PMC members approved the change.

When it comes to code-related changes, the reviews are vague, and it is
really hard (impossible?) to find consensus.
On top of that, the review is complicated by the fact that **multiple**
fixes are needed for log4j 1.x
1) There are multiple known CVEs regarding 1.x
2) 1.x uses a really old build system, so, in my opinion, the build scripts
should be updated before any other changes

Vladimir

Re: Resurrecting log4j 1.x

[Ron Grabowski]

Vladimir, wouldn't a more efficient approach be to offer support to 
Logging Services then have them make a release to address the recent CVE 
while still maintaining 1.2.17 compatibility? I don't get the sense 
folks are against fixing things. Re-starting the entire EOL'ed Log4j1 
engine with a new crew to fix one issue is confusing. To answer your 
question about sponsorship, I want to explore partnering with Logging 
Services before forming a new Log4j1 team.


On 12/20/2021 11:15 AM, Gary Gregory wrote:

I don't see the need for the incubator or a new PMC, this is a recipe for
confusion for users and contributors: Log4j 1 is a component of the Apache
Logging Services project and should remain for Apache to provide the best
and consistent *story* for Java logging, at Apache at least.

Things are bad enough when a product or projects offers pluggable logging
and I have have to explain facades like Log4j API, Jetty Logging, slf4j,
etc, and then implementations of APIs like Log4j Core, Logback, etc, and
then explain when and how to use bridges.

I wrote the above to make the point that reintroducing log4j 1 as a first
class citizen is going to make an even bigger and confusing mess.

The only work we should allow is a 1.2.x release that fixes CVEs.

We should continue to evangelize migration to 2.x.

Gary


On Mon, Dec 20, 2021, 09:36 Ralph Goers  wrote:


I am sure any number of PMC members would be happy to act as sponsors &
mentors. However, before
you even start you need to know if you have enough people who want to
participate tin the project. The
application form needs to include the list of names of people who will
become the initial members of the project.

The reason I brought this up is that it seems there are two groups here.
One that wants to get a release
out and then put Log4j 1 back in the coffin and another that wants to
resurrect it.

Ralph



On Dec 20, 2021, at 7:06 AM, Vladimir Sitnikov <

sitnikov.vladi...@gmail.com> wrote:

Ron,

There's a need to move log4j 1.x forward, and Ralph Goers suggested
that the way to go is to re-incubate it, see [1].

Could you sponsor the project or do you want Incubator to do that? (see

[2])

[1]: https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5
[2]: https://lists.apache.org/thread/c2362g4m4m4y1n7zl444ncvhmfb9oy0m

Vladimir

Re: Resurrecting log4j 1.x

[Gary Gregory]

I don't see the need for the incubator or a new PMC, this is a recipe for
confusion for users and contributors: Log4j 1 is a component of the Apache
Logging Services project and should remain for Apache to provide the best
and consistent *story* for Java logging, at Apache at least.

Things are bad enough when a product or projects offers pluggable logging
and I have have to explain facades like Log4j API, Jetty Logging, slf4j,
etc, and then implementations of APIs like Log4j Core, Logback, etc, and
then explain when and how to use bridges.

I wrote the above to make the point that reintroducing log4j 1 as a first
class citizen is going to make an even bigger and confusing mess.

The only work we should allow is a 1.2.x release that fixes CVEs.

We should continue to evangelize migration to 2.x.

Gary


On Mon, Dec 20, 2021, 09:36 Ralph Goers  wrote:

> I am sure any number of PMC members would be happy to act as sponsors &
> mentors. However, before
> you even start you need to know if you have enough people who want to
> participate tin the project. The
> application form needs to include the list of names of people who will
> become the initial members of the project.
>
> The reason I brought this up is that it seems there are two groups here.
> One that wants to get a release
> out and then put Log4j 1 back in the coffin and another that wants to
> resurrect it.
>
> Ralph
>
>
> > On Dec 20, 2021, at 7:06 AM, Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote:
> >
> > Ron,
> >
> > There's a need to move log4j 1.x forward, and Ralph Goers suggested
> > that the way to go is to re-incubate it, see [1].
> >
> > Could you sponsor the project or do you want Incubator to do that? (see
> [2])
> >
> > [1]: https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5
> > [2]: https://lists.apache.org/thread/c2362g4m4m4y1n7zl444ncvhmfb9oy0m
> >
> > Vladimir
>
>

Re: Resurrecting log4j 1.x

[Gary Gregory]

"need to move log4j 1.x forward"

If this means more than only fixing CVEs it will create a giant hairball of
confusion for users between 1.x and 2.x.

Gary

On Mon, Dec 20, 2021, 09:06 Vladimir Sitnikov 
wrote:

> Ron,
>
> There's a need to move log4j 1.x forward, and Ralph Goers suggested
> that the way to go is to re-incubate it, see [1].
>
> Could you sponsor the project or do you want Incubator to do that? (see
> [2])
>
> [1]: https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5
> [2]: https://lists.apache.org/thread/c2362g4m4m4y1n7zl444ncvhmfb9oy0m
>
> Vladimir
>

Re: Resurrecting log4j 1.x

[Ralph Goers]

Yes, that is certainly a possibility. For that I don’t think a trip through the 
incubator would be necessary. 
But it would also be difficult to make the folks working on log4j 1.x 
committers of the Logging Services 
project since gaining commit rights to an ASF project usually requires more 
than just submitting one or 
two patches.

Ralph

> On Dec 20, 2021, at 8:03 AM, Andrii Berezovskyi  wrote:
> 
> Dear Ralph,
> 
>> The reason I brought this up is that it seems there are two groups here. One 
>> that wants to get a release 
>> out and then put Log4j 1 back in the coffin and another that wants to 
>> resurrect it.
> 
> Do you think there may be a middle ground here? In other words, users who 
> think that log4j is "done" and does not need new features, but at the same 
> time realise that new security issues could pop up in the future and require 
> a release done quickly once a year or so?
> 
> Best regards,
> Andrew
> 
> 

Re: Resurrecting log4j 1.x

[Andrii Berezovskyi]

Dear Ralph,

> The reason I brought this up is that it seems there are two groups here. One 
> that wants to get a release 
> out and then put Log4j 1 back in the coffin and another that wants to 
> resurrect it.

Do you think there may be a middle ground here? In other words, users who think 
that log4j is "done" and does not need new features, but at the same time 
realise that new security issues could pop up in the future and require a 
release done quickly once a year or so?

Best regards,
Andrew

Re: Resurrecting log4j 1.x

[Vladimir Sitnikov]

The key question is who will be the sponsor: Logging or Incubator.

>However, before you even start you need to know
>if you have enough people who want to participate tin the project

I'm sure there are 3-5 persons that would be willing to cooperate.

Vladimir

Re: Resurrecting log4j 1.x

[Ralph Goers]

I am sure any number of PMC members would be happy to act as sponsors & 
mentors. However, before 
you even start you need to know if you have enough people who want to 
participate tin the project. The 
application form needs to include the list of names of people who will become 
the initial members of the project.

The reason I brought this up is that it seems there are two groups here. One 
that wants to get a release 
out and then put Log4j 1 back in the coffin and another that wants to resurrect 
it.

Ralph


> On Dec 20, 2021, at 7:06 AM, Vladimir Sitnikov  
> wrote:
> 
> Ron,
> 
> There's a need to move log4j 1.x forward, and Ralph Goers suggested
> that the way to go is to re-incubate it, see [1].
> 
> Could you sponsor the project or do you want Incubator to do that? (see [2])
> 
> [1]: https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5
> [2]: https://lists.apache.org/thread/c2362g4m4m4y1n7zl444ncvhmfb9oy0m
> 
> Vladimir

Resurrecting log4j 1.x

[Vladimir Sitnikov]

Ron,

There's a need to move log4j 1.x forward, and Ralph Goers suggested
that the way to go is to re-incubate it, see [1].

Could you sponsor the project or do you want Incubator to do that? (see [2])

[1]: https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5
[2]: https://lists.apache.org/thread/c2362g4m4m4y1n7zl444ncvhmfb9oy0m

Vladimir