> Scott, could you (or anybody else) spare time to perform the following
> maintenance tasks?
I don't use chainsaw personally, however, I am afraid I might run into
a project that does, so I would prefer to keep docs afloat.
Volkan,
Does the deal qualify for log4j 1.x?
I would love to resolve iss
> The problems isn’t “not removing links”, it is that there is always a cost to
> saying something is still supported even if no one is doing any actual work
> on it. The longer the code goes untouched the longer that “future cost”
> becomes. Eventually someone has to do something. If no one eve
> The difference is between saying nothing (what we do now) and committing to
> future work (support for 5-10 years and then make it go away).
I am afraid I do not understand it.
Could you explain it in more words?
What is exactly the difference?
Currently, it looks like the cost of "not removin
>> WRT 5-10 years... uh? Where would those numbers come from?
I mean "at least 5-10 years". It costs virtually nothing, so why touch it?
>to anything in that time frame outside of a commercial support contract.
How much money do you need to "not remove chainsaw" from the webpage?
As of now, it l
> Chainsaw is hardly getting any maintenance
It is sad the PMC rejects CVE fixes.
>> [1] Retirement translates to archival of the repository and clearing up its
> mentions in `logging.apache.org`.
It sounds awful to "deprecate and remove references" simultaneously.
How should users know somethin
-1, don't release, because...
Volkan,
I have downloaded the release artifact apache-log4j-tools-0.4.0.zip, and I
fail to find the source package there.
Would you please advise?
See
https://www.apache.org/legal/release-policy.html#what-must-every-release-contain
>Every ASF release must contain
Alternative options could be:
a) Divert GitBox notifications to a separate mailing list (e.g.
issues-gitbox@) which no one really subscribes.
The key issue with GitBox notifications is that it produces messages that
do not group by subject,
so 5 notifications on a single PR might look like 5 diffe
>1. It is an exact copy of log4j-1.2-api with the binary, source, and
javadoc jars renamed to log4j:log4j.
>2. The pom.xml has a dependency on log4j-1.2-api and the jar file is empty.
The options are bad as log4j-1.2-api misses several classes that are used a
lot in log4j 1.x deployments.
For inst
Christian>vote in this thread, which is, btw not meant for discussion but
for voting.
We are on a [DISCUSS] thread (check the subject).
Ralph "created" [DISCUSS] thread by hitting "reply" and changing the
subject.
"reply" keeps message-id, so it might look like a single thread.
See both "[DISCUS
>Log4j is owned by the Logging Services PMC. You cannot incubate it without
this PMC’s approval.
Exactly. As far as I understand, Logging pmc should accept patches and
release fixes or they should approve reincubating.
Of course, you can try rejecting patches and disapprove reincubation,
however,
If you are not interested in maintaining 1.x, please give it away (to
another pmc or add pmc members) and that is it.
Even if you all vote for option 1, then I would just reincubate 1.x or find
an alternative route to make 1.2.18, 1.2.19 and so on. So what is the point
of this vote then? You can't
-1 as it is invalid to say the project is "end of life" provided there are
people willing to support it.
Vladimir
Leo, All,
I've reviewed Leo's changes and filed a PR
https://github.com/apache/logging-log4j1/pull/18
CI: https://github.com/vlsi/log4j/runs/4652588702
I think it is worth separating "build script refactoring" from "bugfix"
changes.
Does anybody have cycles to review and merge "build script refa
>Last I recalled I was a PMC member of this group.
>Probably check the link again you sent
Sorry for that, I misinterpreted the data (I watched bold records only for
unknown reasons).
The initial calculation by Ralph was right.
Vladimir
1) I stand corrected, I misinterpreted the phonebook (I watched on bold
records only), so your calculation was correct. Sorry for that.
> which was only started 19 hours ago
"vote count != consensus", and the key we seek is consensus (e.g.
agreement).
For instance, if the tally is like +5 -2, the
>a. Make the build work with a modern version of Maven.
>b. Fix the Java version bug.
>c. Fix CVE-2021-4104 (expanded to address all JNDI components)
>d. Fix CVE-2019-17571
>allow development to continue, including bug fixes and enhancements
+1 to all that, including new source
Sicker, Ron Grabowski, and Remko Popma
Binding -1 votes were received from Gary Gregory and Christian Grobmeier
A non-binding +1 vote was received from Carter Kozak, Robert Middleton,
Volkan Yazici, Vladimir Sitnikov
Vladimir
Dominik,
Are you willing to add committers and PMC members to the log4j 1.x
community?
If you forbid issues and pull requests, then it goes against the idea of
adding new commuters and PMC members for 1.x.
How do you expect to nominate committers and PMC members if you
forbid pull requests, forb
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 v
+1
Please use the existing apache/log4j repository, and rename it accordingly
Vladimir
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
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 r
>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
>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
>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
> 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/displa
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
Gary>If you manage your Maven (for example) POM properly,
Gary>and you assemble a distribution you'll only end up with the latest
version.
Then I don't truly understand what did you mean by mentioning "Jar hell".
I claim that removal of NTEventLogAppender can't cause "jar hell"
because people eit
Gary,
If someone manages to have **both** log4j-1.2.17.jar **and**
log4j-1.2.18.jar
on the same classpath, nothing can help them. Really.
Binary compatibility can't heal that.
Even if 1.2.18 was fully binary compatible, adding both jars to the
classpath
would blow the system anyway.
In other wor
>Would - in this case - an 1.2.18 with a NoOp NTEventLogAppender be OK?
I am sure 1.2.18 with NoOp (or even throwing NTEventLogAppender unless a
silence system property is set)
appender would be more than enough for 1.2.18
If the appender is not used in the wild, we are ok.
If somebody still uses
>using maven toolchain feature
Are toolchains really needed, especially, 1.6 and 1.7?
I believe Java "target=1.4" + Java 1.8 would be good enough.
If there are javadoc "warnings or errors", we could just suppress it.
At the end of the day, making the build 100 times harder by requesting Java
1.6
l
>All logging services Git repos start with logging-.
I'm 100% sure INFRA can rename `apache/log4j` into `apache/logging-log4j1`,
and it would be transparent for GitHub users.
GitHub would automatically redirect from apache/log4j to
apache/logging-log4j1
>Of course you are free to screw around
Ju
Leo>Instead of or in addition to some of those fixes
I would suggest the following (in case you wonder, I might volunteer to do
ALL of that, so don't assume I just sit and tell others how things should
be done):
1. Use the existing repo https://github.com/apache/log4j instead of a newly
created on
Ralph, thank you.
Why did you create a new repository?
AFAIK, infra could reopen the old one on request.
Vladimir
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
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 reques
Matt>I'm not against applying patches to the svn repo, either.
How about pull requests at GitHub?
Vladimir
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/6lhkyytvpg4md757tfydb1k0mmp5
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
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.
>Wouldn’t enabling issues imply that issues can be filed for an EOL
component?
You can configure a filter to delete the mails automatically.
On the other hand, it would be nice to know if there are issues like memory
leak.
I do not see a strong need for issue tracker yet. I just wanted to clarif
>reactivate Bugzilla or create a Jira for Log4j 1, movie it to GitHub, etc.
"Moving to GitHub" is a no-op, as the current git mirror is ok.
Bugzilla and JIRA are not needed. GitHub Issues can be activated via single
line in asf.yml
All this is trivial thanks to the infra team.
Vladimir
>The alternative is to polish the 1.x compatibility in 2.x
Making sure the compatibility is 100% would be way harder than reincubating
1.x
"maintaining" and "releasing" 1.x is not hard (e.g. I can do it), so I do
not buy "1.x is not maintained".
Vladimir
Matt>but at least one release using the normal ASF release requirements is
required to graduate.
Thanks for the reminder, and I am sure preparing the release won't be an
issue. I refactored release scripts for both Calcite and JMeter, and I am
sure log4j 1.x is doable.
>compared to the alternativ
>All new ASF projects go through the incubator. Sub-projects don’t have to
but when an entirely new community is being
I'm a member of PMC Calcite and JMeter, however, I have not submitted
projects to the incubator yet.
> Once graduated the podling
PMC members would become part of the Logging Ser
Ralph>if you want to resurrect the project then this really should go
through
Ralph>the ASF incubator with the Logging Services project as the sponsor
Ralph,
Do you think you know similar cases?
Could you please suggest the procedure for resurrection?
I guess it would look strange if I submit a m
>Could it make sense to limit recursion to a few levels (e.g. 3 or 5) by
default,
+1
Unlimited recursion is a disaster waiting to happen.
Adding a hard limit makes sense.
Vladimir
>I think we would
have to create a new repo and make the PR against the new repo
instead.
Why create a new repo? The current is just fine.
For instance, I migrated Apache JMeter from SVN to Git, and extra git
repositories were not needed.
See
https://issues.apache.org/jira/browse/INFRA-18499?foc
>From my side what I volunteered for is to propose changes that should go in
>that fix for review.
Thank you.
>Similarly to set up git(hub) requires a PMC member.
>Hopefully the [VOTE] on that is revisited and then someone sets it up.
Would you please express your opinion on "[VOTE] Move log4j 1
>If we do need an issue tracker I would suggest enabling the github one
>after making that a writable repo
+1. If we need a tracker, then GitHub issues is the way to go.
>Note removing the classes would break API compatibility
I do not think keeping the class with "every method throws" is much b
Migrating via compatibility layers is way harder for consumers, and it does
not sound like a proper plan for fixing RCE.
The scope of regression testing from 1.x to 2.x+compatibility would be much
more for the consumers than the scope of 1.2.17 -> 1.2.18, so it would be
way harder for them to test
I thought there was an agreement on releasing 1.2.18 as "networkless"
release.
I think moving to Git (which is a no-op basically), would greatly simplify
that.
>1.x has been EOL since 2015
There's a demand for fixing CVEs in 1.x
>with possible confusion as to which version
>1.x vs 2.x to use in
Hi,
I suggest log4j 1.x moves from SVN to Git.
I do not expect to have great development, however, moving to Git would make
it easier to contribute and review changes.
[ ] +1 let's move to Git and make SVN read-only
[ ] -1 don't do that because ...
Here's my vote: +1
Vladimir
>How would we then be able to ever release a log4j-1.2.19 jar if we find
>another security vulnerability?
I hope 1.2.19 won't be needed ;)
>I believe that 1.2.17 targets Java 1.4(!)
Java 1.8 can target 1.4 bytecode.
>Also, I think we can consider not supporting any appenders that require
>nativ
>My understanding is it requires an extremely
>old JDK.
>Have you actually tried building the project to see if this is true?
I was able to build the project with Maven3 and Java 1.8 by commenting out
tools.jar, "site-related", "antrun-related" stuff in pom.xml.
It did produce logj4.jar that worke
Hi,
I hope log4j finds you well :)
I know log4j 1.x has reached its end of life long ago,
however, I wonder if there's a possibility to ship 1.2.18 with
"network-related" classes removed.
The list of classes I suggest removing:
* JMSAppender: it looks like it might cause "remote code execution"
56 matches
Mail list logo
