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 an application from a 3rd party that you need to use but the vendor won't update because it's EOL or something like that). Dropping the new JAR in should be good enough to mitigate security vulnerabilities for those applications. -Robert Middleton On Sat, Dec 18, 2021 at 7:52 AM Vladimir Sitnikov <sitnikov.vladi...@gmail.com> wrote: > > >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.x from SVN to > Git..." thread? > Non-committers can vote. > > Frankly speaking, it is really sad that committers and PMCs are silent > regarding 1.x security. > The Git mirror already exists, making SVN read-only is trivial. > I do not believe it takes that much effort to vote for the migration. > I do not really understand the reasons behind vetoing the move to Git. > Why veto the security fix for log4j 1.x in case you are not interested in > 1.x development? > > If all the current members for PMC logging are indifferent regarding 1.x, > can there be a new PMC for log4j 1.x? > > >In that case we can put an unofficial release somewhere on github. > > I think there are many forks that fix 1.x security, especially, in-house > ones. > For instance, https://github.com/JetBrains/intellij-deps-log4j > > Vladimir
