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

Reply via email to