(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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 < > >> [email protected]> 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 > >> > >
