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
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
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 l
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
*
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
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 no
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 wrot
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 ki
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
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
> 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,
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
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
>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
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 ha
>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
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, y
>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
>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 knowle
> 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
> 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 thi
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
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
no
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 d
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.
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? W
(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 fr
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 po
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 thi
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
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
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 +
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
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 demot
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
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, V
Matt>I'm not against applying patches to the svn repo, either.
How about pull requests at GitHub?
Vladimir
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 minima
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" f
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
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
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 ne
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
"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
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
tha
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
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
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 memb
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.
49 matches
Mail list logo
