The main point is, I thought, we agreed to not say/do anything until we
have a PLAN. See also Ralph's request to call for a VOTE or wrap up the
email with the list of options.
Gary
On Tue, Dec 28, 2021 at 2:08 PM Matt Sicker wrote:
> I looked through most of the PR (besides the pom changes).
I looked through most of the PR (besides the pom changes). Seems good so far,
but I’d like someone else to also verify.
--
Matt Sicker
> On Dec 28, 2021, at 12:36, Vladimir Sitnikov
> wrote:
>
> Leo, All,
>
> I've reviewed Leo's changes and filed a PR
>
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
On Thu, Dec 23, 2021, at 16:39, Leo Simons wrote:
> On Thu, 23 Dec 2021 at 15:43, Christian Grobmeier
> wrote:
>
>> I didn't see the PRs though - are they still local on your box?
>
>
> On the wrong repo and lacking a target branch:
>
> https://github.com/apache/log4j/pull/17
>
Leo,
I have created the main branch from the v1_2_17 tag. It looks like I will have
to create a
Jira for Infra to switch the default as it looks like we don’t have access to
the GitHub
tooling to do that.
Ralph
> On Dec 23, 2021, at 8:39 AM, Leo Simons wrote:
>
> On Thu, 23 Dec 2021 at
On Thu, 23 Dec 2021 at 15:43, Christian Grobmeier
wrote:
> I didn't see the PRs though - are they still local on your box?
On the wrong repo and lacking a target branch:
https://github.com/apache/log4j/pull/17
https://github.com/apache/log4j/pull/16
From
https://github.com/lsimons/log4j
For
Hi
On Thu, Dec 23, 2021, at 14:51, Leo Simons wrote:
> Thanks for chipping in Christian! Your detailed notes from back then helped
> a ton figure basic things out.
>
> What I did for the PRs I made is to
>
> * also check in the 32 bit 1.2.17 dll from the binary release, like was
> already done
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
On Thu, Dec 23, 2021 at 8:48 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> 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.
>
You're confusing
Fwiw, this sounds like a god plan to me.
Ralph
> On Dec 23, 2021, at 6:51 AM, Leo Simons wrote:
>
> Thanks for chipping in Christian! Your detailed notes from back then helped
> a ton figure basic things out.
>
> What I did for the PRs I made is to
>
> * also check in the 32 bit 1.2.17 dll
Thanks for chipping in Christian! Your detailed notes from back then helped
a ton figure basic things out.
What I did for the PRs I made is to
* also check in the 32 bit 1.2.17 dll from the binary release, like was
already done for 64 bit,
* have the maven build not auto-attempt to build it,
*
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
On Thu, Dec 23, 2021 at 8:31 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> >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
On Thu, Dec 23, 2021 at 8:20 AM Christian Grobmeier
wrote:
>
> On Thu, Dec 23, 2021, at 14:05, Gary Gregory wrote:
> > One of the difficulties was likely related to building the Windows DLLs
> > for
> > using the Windows Event Log Appender (
> >
>
>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
On Thu, Dec 23, 2021, at 14:05, Gary Gregory wrote:
> One of the difficulties was likely related to building the Windows DLLs
> for
> using the Windows Event Log Appender (
> https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/nt/NTEventLogAppender.html).
> I remember that being
One of the difficulties was likely related to building the Windows DLLs for
using the Windows Event Log Appender (
https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/nt/NTEventLogAppender.html).
I remember that being challenging. I can't recall if we signed the DLLs
like we might do for
Hello
I have been the person cutting the 1.2.17 release and what I remember was it
was a super hard build. I had to install some VMs because there were weird
dependencies to this build. Building it fully will not be easy, but I can also
look into some mails whatever I found from that time.
Improving legacy compatibility is what I've been pushing. I agree with
Matt. IMO resurrecting 1.x sets a bad precedent and is a proverbial can of
worms.
Gary
On Sun, Dec 19, 2021, 17:55 Matt Sicker wrote:
> The alternative is to polish the 1.x compatibility in 2.x which is both
> actively
>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
Wouldn’t enabling issues imply that issues can be filed for an EOL component? I
don’t see the difference between enabling issues and writing them to /dev/null
besides unnecessary emails.
--
Matt Sicker
> On Dec 19, 2021, at 17:23, Vladimir Sitnikov
> wrote:
>
>> reactivate Bugzilla or create
>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
> On Dec 19, 2021, at 3:48 PM, Vladimir Sitnikov
> wrote:
>
> 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
>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
The alternative is to polish the 1.x compatibility in 2.x which is both
actively maintained and much easier to get releases published. Then users on
1.x can more easily upgrade to 2.x. I can almost guarantee that regardless of
how many warnings we add to a potential 1.x release, we’ll get
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
I think PDFBox and/or POI did something like that with XML Beans.
Gary
On Sun, Dec 19, 2021 at 5:10 PM Matt Sicker wrote:
>
> I thought there was some old XML library that was resurrected here at Apache
> because other PMCs were still using it as a dependency. That might have been
> more so
I thought there was some old XML library that was resurrected here at Apache
because other PMCs were still using it as a dependency. That might have been
more so related to the Attic.
Anyways, as can be seen already, making non-controversial changes to 1.x that
both the PMC and our users could
WRT words, IIRC Apache only has top-level projects (for example,
Apache Logging Services, Apache Commons, Apache HttpComponents),
within that you can have components, not other projects, for example,
Apache Log4j, Apache Commons IO, Apache HttpComponents HttpCore.
Gary
On Sun, Dec 19, 2021 at
The Logging Services project is an “umbrella” project that manages all the
logging projects, including Log4j 1.x.
We would not be in favor of having Log4j 1.x become a new standalone PMC.
But yes, any Logging Services PMC member can veto a code change in any of the
sub-projects.
I don’t know
>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
I should have said, you would have to publish at least one release in the
incubator to qualify to graduate. Once graduated the podling
PMC members would become part of the Logging Services PMC.
Ralph
> On Dec 19, 2021, at 2:00 PM, Ralph Goers wrote:
>
> The process is that a form gets filled
The process is that a form gets filled out in the Incubator’s Confluence wiki.
The form lists the proposed podling PMC members.
It isn’t strange at all for the people to then send an email to the incubator
list. If that is what you are contemplating then you
should start at
On Sun, Dec 19, 2021 at 3:33 PM Vladimir Sitnikov
wrote:
>
> 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
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
A hard -1
Thank you for pitching in but this PR completely breaks major blocks
of functionality.
I see comments like "Changed in 1.2.18+ to complain about its use and
do nothing else." for the JDBC Appender, Telnet Appender,
ExternallyRolledFileAppender, JMS Appender, JMX, and more! 140 files
Hey folks,
So as requested I've made a conservative fully binary compatible version of
all the build changes and security fixes, patches are on a new pull request
at
https://github.com/apache/log4j/pull/17
On Sat, Dec 18, 2021 at 7:30 PM Gary Gregory wrote:
> Again, you cannot break
Hello everyone,
Please look at the RedHat CVE report made concerning log4j-v1 some time
ago: https://access.redhat.com/security/cve/cve-2017-5645
RedHat made the fix, presumably for the sake of RedHat users that for one
reason or another were stuck on log4j-v1. Once log4j-1 has moved to git
then
Chainsaw was extracted into its own repository, so those changes are probably
ok at least.
—
Matt Sicker
> On Dec 18, 2021, at 12:17, Leo Simons wrote:
>
> On Sat, Dec 18, 2021 at 5:32 PM Leo Simons wrote:
>
>>> On Sat, Dec 18, 2021 at 3:34 PM Gary Gregory
>>> wrote:
>>>
>>> If you
Again, you cannot break binary compatibility in a minor release. That's a
show stopper.
This discussion IMO should ONLY be about mitigation of CVEs and that means
porting the idea of the fixes from 2.x to 1.x. This 1.x component is EOL. I
say "idea" because the code bases for 1.x and 2.x are
On Sat, Dec 18, 2021 at 5:32 PM Leo Simons wrote:
> On Sat, Dec 18, 2021 at 3:34 PM Gary Gregory
> wrote:
>
>> If you delete anything that is public or protected, you will break
>> binary compatibility, and that's a no-go IMO.
>
>
> Agree. I hope we can get clirr (or something like it) back to
Hey,
On Sat, Dec 18, 2021 at 1:52 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> >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.x from
Hey Gary,
On Sat, Dec 18, 2021 at 3:34 PM Gary Gregory wrote:
> If you delete anything that is public or protected, you will break
> binary compatibility, and that's a no-go IMO.
Agree. I hope we can get clirr (or something like it) back to work, to
prove binary compatibility.
Perhaps with
If you delete anything that is public or protected, you will break
binary compatibility, and that's a no-go IMO. If are going to really
want to release anything, you'll want to disable JNDI by default and
add an enablement property as we did for 2.17.0.
Gary
On Sat, Dec 18, 2021 at 9:13 AM
I can do the security release if something exists in a good state.
The reasoning for me is that there are still many applications that
exist that have not upgraded, even though it's been 6+ years.
If it is binary compatible as well, that makes upgrades easy(I'm
thinking of a case where you have
>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
Hey,
TL;DR: I have no intention to contribute anything but a security fix, and
I don't think there's anyone who thinks differently.
I'll provide a patch but won't/can't make the official release.
>From my side what I volunteered for is to propose changes that should go in
that fix for review.
I
It's possible that it's not buildable without updates to the build
scripts. If that's the case, then they should be updated.
On Fri, Dec 17, 2021 at 12:28 PM Ralph Goers wrote:
>
> I am still questioning the plan. If you are planning on just creating a
> security release
> and then having the
I am still questioning the plan. If you are planning on just creating a
security release
and then having the project go back to its coffin then I am not sure why all
the tooling
is needed. OTOH, if you want to resurrect the project then this really should
go through
the ASF incubator with
Hey,
Progress today
As mentioned I made a draft PR for the branch I'm working on:
https://github.com/apache/log4j/pull/16
My main progress today was to get the unit test suite working reliably
(dozens of tests were disabled because they had flaky results), and then to
get build and
50 matches
Mail list logo
