Hi Andor, Thank you for feedback!
I will open a sample patch once it is ready. Best, Kezhu Wang On Thu, Aug 14, 2025 at 6:40 PM Andor Molnar <an...@apache.org> wrote: > > Sounds good to me. Could you please create a sample patch similar to mine in > order to see how it’d look like in action? > > Using slf4j-simple looks like feasible, but the patch is complicated and > still not ready, so I’d really appreciate something else. > > Andor > > > > > On Aug 13, 2025, at 22:21, Kezhu Wang <kez...@gmail.com> wrote: > > > > Hi Andor, > > > > Thank you for the summary! > > > >> also drop the jar from release artifacts > > > > No jar is dropped but the test dependency entry in pom.xml. That is > > there will be no `logback-classic` in pom.xml in the published jar. > > So, external dependants are free to do whatever they want to do. We > > could keep slf4j at 1.x in 3.9 and 3.8 for backward compatibility and > > to reduce the chance of "no provider" and "no logs". > > > >> bump logback / slf4j version to secure ones: 1.3.x, 2.0.x > > > > This is only needed for zookeeper-assembly to assemble published tarbal. > > > > Nothing more. > > > > The possible consequence of this approach is "no provider" warning > > from slf4j and "no logs" in execution which is noticeable. The > > reaction from dependants is also simple: add or bump log dependency. > > > > In contrast, replacing logback with slf4j-simple could function > > normally but differently which is less noticeable. Besides, > > administrators probably will have to configure log dependencies to > > gain the same log behaviors in upgrading. > > > > Best, > > Kezhu Wang > > > > On Thu, Aug 14, 2025 at 10:44 AM Andor Molnar <an...@apache.org> wrote: > >> > >> Thanks Kezhu, I can support this approach too, but Christopher might have > >> some concerns. Let’s see if I understand it well. > >> > >> TL;DR > >> > >> - change logback-classic to test scope, > >> - use “flatten-maven-plugin” to drop it from published pom (also drop the > >> jar from release artifacts) > >> - bump logback / slf4j version to secure ones: 1.3.x, 2.0.x > >> - do the above on all branches: master, 3.9, 3.8 > >> - create new releases > >> > >> Did I miss anything? > >> > >> Andor > >> > >> > >> > >>> On Aug 13, 2025, at 20:29, Kezhu Wang <kez...@gmail.com> wrote: > >>> > >>> Hi all, > >>> > >>> ZooKeeper delivers two shapes of artifacts to clients: > >>> 1. Java library mainly for client usage. > >>> 2. Deployable java server application. > >>> > >>> I think we could take different actions based on usage. > >>> 1. For library usage, ZooKeeper depends only on `slf4j-api` and should > >>> not ship any log framework dependencies. I saw ZOOKEEPER-4820[1], > >>> there are discussions to mark `logback-classic` as optional runtime > >>> dependency[2]. I would suggest we change it to test scope and use > >>> maven plugin "flatten-maven-plugin" to drop test dependencies from > >>> published pom.xml to express the fact that zookeeper library does not > >>> depend on nor prefer concrete log frameworks. This way, the library > >>> usage would not be affected by any CVEs of logback. > >>> 2. For application usage, ZooKeeper ships both slf4j and logback. I > >>> think we can bump both in zookeeper-assembly and add release notes to > >>> highlight the consequence of this change. > >>> > >>> After the above actions, there is only one possible breaking change > >>> for application usage: administrators have to check possible > >>> customized log dependencies in zookeeper deployment to meet slf4j > >>> requirements, otherwise there will be "no provider" warning from slf4j > >>> and hence no logs. I think the risk is pretty low, it affects only > >>> deployments with customized log dependencies which should be taken > >>> care of by administrators themselves. > >>> > >>> Regarding replacing logback with slf4j-simple, I think it is ok for > >>> tests. But will it cause much bigger breaking change than bumping > >>> slf4j and logback for application artifacts ? > >>> > >>> Best, > >>> Kezhu Wang > >>> > >>> [1]: https://issues.apache.org/jira/browse/ZOOKEEPER-4820 > >>> [2]: https://github.com/apache/zookeeper/pull/2155#discussion_r1559857699 > >>> > >>> > >>> On Thu, Aug 14, 2025 at 2:22 AM Enrico Olivelli <eolive...@gmail.com> > >>> wrote: > >>>> > >>>> Il Mer 13 Ago 2025, 19:56 Andor Molnar <an...@apache.org> ha scritto: > >>>> > >>>>> I’ve created a PR to attempt to replace logback with slf4j-simple. We do > >>>>> have some test code relying on logback’s appenders, but we might be > >>>>> able to > >>>>> replace it with a basic output stream. > >>>>> > >>>>> https://github.com/apache/zookeeper/pull/2293 > >>>>> > >>>>> > >>>>> ptal. > >>>>> > >>>> > >>>> Overall I agree with the approach. I left a couple of questions about the > >>>> impact on client users and server system admins > >>>> > >>>> I am +1 to release 3.10 and send 3.8 to EOL > >>>> > >>>> > >>>> > >>>> Thanks > >>>> Enrico > >>>> > >>>> > >>>>> > >>>>> Andor > >>>>> > >>>>> > >>>>> > >>>>>> On Aug 12, 2025, at 15:58, Christopher <ctubb...@apache.org> wrote: > >>>>>> > >>>>>> I would NOT ship with reload4j in new releases. That exists only as a > >>>>>> temporary workaround for the lack of patch support for log4j 1.2, > >>>>>> until one is able to update to log4j2 or something else. ZK is already > >>>>>> using something else (logback). Neither log4j 1.2 nor reload4j are > >>>>>> appropriate for use with slf4j2. If a log4j implementation is desired, > >>>>>> a log4j 2.x version should be used. Using reload4j would be a step in > >>>>>> the wrong direction. > >>>>>> > >>>>>> However, since ZK uses slf4j-api in code, I would ship *only* with > >>>>>> slf4j-simple as the trivial reference implementation, and let users > >>>>>> determine their own runtime logging dependency and configuration, > >>>>>> which can be trivially swapped in place of slf4j-simple. This is > >>>>>> basically what I argued when logback was being considered to replace > >>>>>> log4j/reload4j a few years ago, but others preferred logback. > >>>>>> > >>>>>> One thing to consider is that, if I remember correctly, logback is > >>>>>> used as a test dependency for some build tests. It is easier to run > >>>>>> those tests with logback than it is to do it with another runtime > >>>>>> dependency. It is possible to have the tests run using logback, but > >>>>>> still ship with slf4j-simple instead of logback, but it may take some > >>>>>> careful attention to the Maven pom.xml files to ensure the desired > >>>>>> result (let's call this the "split dependency" option). It is > >>>>>> certainly easier to stay with logback ("single dependency option"), > >>>>>> but just update it to a newer version, than to modify the Maven build > >>>>>> to ship something different than what is used in testing, but both > >>>>>> options are technically possible. > >>>>>> > >>>>>> > >>>>>> On Fri, Aug 8, 2025 at 5:19 PM Andor Molnar <an...@apache.org> wrote: > >>>>>>> > >>>>>>> Yeah, I totally agree. > >>>>>>> > >>>>>>> The plan to go forward after getting 3.9.4 out of the door is to > >>>>>>> either > >>>>> remove logback from branch-3.8 and replace it with something simpler > >>>>> like > >>>>> slf4j-simple or reload4j since we ship the logback dependency as an > >>>>> example. Though I’m not sure if slf4j-simple is an option for us, I > >>>>> have to > >>>>> try it out in action. > >>>>>>> > >>>>>>> The other option is to announce EoL on branch-3.8 and encourage users > >>>>> to upgrade to 3.9.4. At the same time we have to create a 3.10.0 release > >>>>> off the main branch or maybe 4.0.0. I don't have a strong opinion here > >>>>> either, but I’m pretty confident that we should drop Java 8 support in > >>>>> the > >>>>> next “current” release. > >>>>>>> > >>>>>>> Andor > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> On Aug 8, 2025, at 15:05, Christopher <ctubb...@apache.org> wrote: > >>>>>>>> > >>>>>>>> I don't think the upgrade to slf4j 2 is purely a semantic one. I > >>>>>>>> think > >>>>>>>> there are genuine incompatibilities, but probably not too many. For > >>>>>>>> example, slf4j2 drops support for Java 7 (probably not a problem for > >>>>>>>> ZK, since I think Java 8 is already a requirement), and it switches > >>>>>>>> the binding mechanisms, so that if somebody was using a different > >>>>>>>> sfl4j runtime other than logback, then it probably won't work anymore > >>>>>>>> without additional changes on the user's part. > >>>>>>>> > >>>>>>>> I think the switch on 3.9 is probably okay, but users should be > >>>>>>>> warned > >>>>>>>> that their logging will probably break if they had used a different > >>>>>>>> runtime binding for slf4j other than the logback version that ships > >>>>>>>> with ZK. > >>>>>>>> > >>>>>>>> As for the differences between logback 1.2 and 1.3, I have no idea... > >>>>>>>> it's probably fine, since ZK is mainly just using it via slf4j-api > >>>>>>>> anyway, rather than using it directly, but I'd start getting > >>>>>>>> concerned > >>>>>>>> that 1.3 is also no longer being developed. ZK should probably get > >>>>>>>> ahead of that on the master branch by requiring Java 11, and using > >>>>>>>> logback 1.5 there, if it hasn't been done already. Or else this > >>>>>>>> question of switching from logback 1.2 to 1.3 is going to come up > >>>>>>>> again soon when there's a CVE found against 1.3 and you have to > >>>>>>>> switch > >>>>>>>> to 1.5 and Java 11.... certainly don't want to do that in a bugfix > >>>>>>>> release from the ZK 3.9 branch. > >>>>>>>> > >>>>>>>> On Thu, Aug 7, 2025 at 9:41 AM Andor Molnar <an...@apache.org> wrote: > >>>>>>>>> > >>>>>>>>> Considering all of this I’ll upgrade logback + slf4j to 1.3/2.0 on > >>>>> the 3.9 branch today and proceed with the release. 3.9 is the current > >>>>> release line and I think this step is still acceptable at this stage. I > >>>>> won’t do the same on the stable (3.8) branch and we should talk about > >>>>> EoL’ing soon in a separate thread. > >>>>>>>>> > >>>>>>>>> Andor > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> On Aug 6, 2025, at 19:56, Andor Molnar <an...@apache.org> wrote: > >>>>>>>>>> > >>>>>>>>>> "The 1.2.x series for logback-core and logback-classic has been > >>>>> deprecated for several years and is no longer maintained. As such, use > >>>>> of > >>>>> the 1.2.x series is discouraged.” > >>>>>>>>>> > >>>>>>>>>> "Logback version 1.3.15 is the latest in the 1.3.x series. It > >>>>> requires SLF4J version 2.0.x and JDK 8. Please note that the 1.3.x > >>>>> series > >>>>> is no loger actively developed.” > >>>>>>>>>> > >>>>>>>>>> "The current actively developed version of logback-core and > >>>>> logback-classic is 1.5.18. It requires JDK 11 and SLF4J version 2.0.1 at > >>>>> runtime.” > >>>>>>>>>> > >>>>>>>>>> Looks like our only option is 1.3.x, but once we drop JDK 8 support > >>>>> (3.10.x maybe?), we’ll be able to upgrade to 1.5. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> On Aug 6, 2025, at 19:52, Andor Molnar <an...@apache.org> wrote: > >>>>>>>>>>> > >>>>>>>>>>> I cannot upgrade logback without upgrading slf4j as well. Build > >>>>> fails. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> On Aug 6, 2025, at 17:07, Patrick Hunt <ph...@apache.org> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> Is slf4j really needed for security? > >>>>>>>>>>>> > >>>>>>>>>>>> Only cve I see here is from 2018... > >>>>>>>>>>>> https://www.slf4j.org/news.html > >>>>>>>>>>>> > >>>>>>>>>>>> Should we revert the slf4j change in its entirety/all branches > >>>>> until it can > >>>>>>>>>>>> be made in a b/w compatible way? > >>>>>>>>>>>> > >>>>>>>>>>>> Patrick > >>>>>>>>>>>> > >>>>>>>>>>>> On Wed, Aug 6, 2025 at 2:59 PM Andor Molnar <an...@apache.org> > >>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Maybe the slf4j upgrade (1.7.30 -> 2.0.13) has higher impact, > >>>>> because it’s > >>>>>>>>>>>>> a major upgrade. Logback is just an example of how to do logging > >>>>> with > >>>>>>>>>>>>> ZooKeeper real life setups probably replace it with something > >>>>> else like > >>>>>>>>>>>>> log4j2. The logging facade (slf4j) could have bw incompatible > >>>>> changes that > >>>>>>>>>>>>> will force users to make changes related to logging on their > >>>>> classpath. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I’m speculating and haven’t checked slf4j for details. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Andor > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> On Aug 6, 2025, at 16:46, Patrick Hunt <ph...@apache.org> > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Is the only problem the minor "semantic" upgrade of logback in > >>>>>>>>>>>>>> a > >>>>> fix > >>>>>>>>>>>>>> release of zk? That should be stable (contract wise) on the > >>>>> dependency, > >>>>>>>>>>>>>> right? Or is there some real impact, eg b/w incompat change > >>>>> visible to ZK > >>>>>>>>>>>>>> users? If the former that seems fine, if the latter then we > >>>>>>>>>>>>>> have > >>>>> a harder > >>>>>>>>>>>>>> problem to address. (security issue breaking b/w compat) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Patrick > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Wed, Aug 6, 2025 at 2:36 PM Andor Molnar <an...@apache.org> > >>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Sorry for the confusion, I picked 3.8 as an example, but > >>>>> logback/slf4j > >>>>>>>>>>>>>>> upgrades haven’t been backported to 3.9 either. Therefore I > >>>>> created the > >>>>>>>>>>>>>>> following backport PR: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> https://github.com/apache/zookeeper/pull/2290 > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> "Why would they be applied to master and not to any active > >>>>> (release) > >>>>>>>>>>>>>>> line? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Since we’ve already released 3.9.3 with logback 1.2.13 and > >>>>> don’t want > >>>>>>>>>>>>>>> users to realize 1.2->1.3 logback upgrade in a 3.9.3->3.9.4 > >>>>> ZooKeeper > >>>>>>>>>>>>>>> upgrade process, although this upgrade is necessary anyways to > >>>>> address > >>>>>>>>>>>>> the > >>>>>>>>>>>>>>> CVE in question. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> (in my understanding) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Andor > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Aug 6, 2025, at 15:34, Patrick Hunt <ph...@apache.org> > >>>>> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I'm confused - this thread started with "OWASP reports CVEs > >>>>>>>>>>>>>>>> on > >>>>> the 3.8 > >>>>>>>>>>>>>>>> branch and noticed in the PRs that we should only upgrade > >>>>> logback on > >>>>>>>>>>>>> the > >>>>>>>>>>>>>>>> master branch" - I read that as "some fixes on 3.9 are not > >>>>> backported > >>>>>>>>>>>>> to > >>>>>>>>>>>>>>>> 3.8". But you are saying that this is not fixed (still owasp > >>>>> warnings) > >>>>>>>>>>>>> on > >>>>>>>>>>>>>>>> 3.9 which is separate from master? Why would they be applied > >>>>> to master > >>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>> not to any active (release) line? What is the impact of the > >>>>> changes on > >>>>>>>>>>>>>>>> master and 3.9? iiuc there are backward incompatible changes > >>>>> if applied > >>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>> 3.8? There should not be b/w incompatible changes applied to > >>>>> any 3.x > >>>>>>>>>>>>>>> (incl > >>>>>>>>>>>>>>>> master, a future 3.x...) release. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Patrick > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Wed, Aug 6, 2025 at 1:16 PM Andor Molnar > >>>>>>>>>>>>>>>> <an...@apache.org> > >>>>> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Yeah, that would remove the burden of maintaining the 3.8 > >>>>> version > >>>>>>>>>>>>> line, > >>>>>>>>>>>>>>>>> but 3.9.x versions still don’t have logback and slf4j > >>>>> upgraded, still > >>>>>>>>>>>>>>>>> flagged by the Owasp build and users will probably still > >>>>> complain > >>>>>>>>>>>>> about > >>>>>>>>>>>>>>>>> CVEs. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> My question is what should we do on branches other than the > >>>>> master? > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> 1. Backport logback and slf4j upgrades from master, or > >>>>>>>>>>>>>>>>> 2. Add Owasp suppression rule to skip checking these > >>>>>>>>>>>>>>>>> libraries > >>>>>>>>>>>>>>> completely. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> I need to answer this question before going forward with the > >>>>> 3.9.4 > >>>>>>>>>>>>>>> release. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>>>>> Andor > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> On Aug 6, 2025, at 13:39, Christopher <ctubb...@apache.org> > >>>>> wrote: > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> +1 to that idea. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> The releases page[1] says "Apache ZooKeeper 3.9.3 is our > >>>>> current > >>>>>>>>>>>>>>>>>> release, and 3.8.4 our latest stable release". Is 3.9 > >>>>> sufficiently > >>>>>>>>>>>>>>>>>> stable to replace 3.8 as the current "stable"? If the > >>>>>>>>>>>>>>>>>> answer > >>>>> is yes, > >>>>>>>>>>>>>>>>>> then I think it makes sense to EOL 3.8. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> [1]: https://zookeeper.apache.org/releases.html#download > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> On Mon, Aug 4, 2025 at 2:52 PM Patrick Hunt < > >>>>> ph...@apache.org> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Should we sunset that minor release due to the "unfixable" > >>>>> security > >>>>>>>>>>>>>>>>> issue > >>>>>>>>>>>>>>>>>>> and EOL of dependenc(ies)? > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Patrick > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On Mon, Aug 4, 2025 at 10:03 AM Andor Molnar < > >>>>> an...@apache.org> > >>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Yeah, I agree with that, but we can’t leave things here > >>>>> just like > >>>>>>>>>>>>>>> that. > >>>>>>>>>>>>>>>>>>>> Either we should keep updating the logging libraries on > >>>>> all active > >>>>>>>>>>>>>>>>> branches > >>>>>>>>>>>>>>>>>>>> or add the necessary suppression to Owasp. Otherwise the > >>>>> report > >>>>>>>>>>>>>>> result > >>>>>>>>>>>>>>>>> will > >>>>>>>>>>>>>>>>>>>> be completely meaningless. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Andor > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> On Aug 4, 2025, at 08:21, Christopher < > >>>>> ctubb...@apache.org> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Yes, that is basically my concern. I commented at > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>> https://github.com/apache/zookeeper/pull/2290#issuecomment-3145955665 > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> On Fri, Aug 1, 2025, 18:43 Andor Molnar > >>>>>>>>>>>>>>>>>>>>> <an...@apache.org> > >>>>> wrote: > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Christopher raised concern about it in > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>> https://github.com/apache/zookeeper/pull/2162#pullrequestreview-2037135095 > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> I suspect because SLF4j has to be major upgraded with > >>>>> logback 1.x > >>>>>>>>>>>>>>> -> > >>>>>>>>>>>>>>>>> 2.x > >>>>>>>>>>>>>>>>>>>>>> which should not be done in bugfix releases. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> I’m not sure. Maybe we should just add another Owasp > >>>>> suppression, > >>>>>>>>>>>>>>> but > >>>>>>>>>>>>>>>>>>>> that > >>>>>>>>>>>>>>>>>>>>>> wouldn’t be appropriate either. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Andor > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> On Jul 30, 2025, at 18:39, Andor Molnar < > >>>>> an...@apache.org> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> That’s my understanding too, but looks like folks > >>>>> skipped even > >>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>> 3.9 > >>>>>>>>>>>>>>>>>>>>>> backport in the case of logback. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Andor > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> On Jul 30, 2025, at 16:36, Patrick Hunt < > >>>>> ph...@apache.org> > >>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> My understanding, I thought the rule was to backport > >>>>> any patch > >>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>> all > >>>>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>>>> the active releases unless it's a new feature. > >>>>>>>>>>>>>>>>>>>>>>>> Perhaps > >>>>> ask the > >>>>>>>>>>>>>>>>> folks > >>>>>>>>>>>>>>>>>>>> who > >>>>>>>>>>>>>>>>>>>>>>>> committed? > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Patrick > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jul 30, 2025 at 2:06 PM Andor Molnar < > >>>>> an...@apache.org > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> Hi folks, > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> Currently I’m working on some backports, because > >>>>> OWASP reports > >>>>>>>>>>>>>>>>> CVEs > >>>>>>>>>>>>>>>>>>>> on > >>>>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>>> 3.8 branch and noticed in the PRs that we should > >>>>>>>>>>>>>>>>>>>>>>>>> only > >>>>> upgrade > >>>>>>>>>>>>>>>>> logback > >>>>>>>>>>>>>>>>>>>>>> on > >>>>>>>>>>>>>>>>>>>>>>>>> the master branch. Why is that? > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> logback-core-1.2.13.jar > >>>>>>>>>>>>>>>>> (pkg:maven/ch.qos.logback/logback-core@1.2.13 > >>>>>>>>>>>>>>>>>>>> , > >>>>>>>>>>>>>>>>>>>>>>>>> cpe:2.3:a:qos:logback:1.2.13:*:*:*:*:*:*:*) : > >>>>> CVE-2024-12798, > >>>>>>>>>>>>>>>>>>>>>> CVE-2024-12801 > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>>>>>>>>>>>>> Andor > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>> > >>>>> > >> >
