Hi, +1 to backport to 3.8 as well, this is the simplest and easiest way.
The result of the possible breaking change is noticeable to be aware of. I have created pr for branch-3.8 and branch-3.9 to note this in the release note. Please take a look. * https://github.com/apache/zookeeper/pull/2298 for branch-3.9 * https://github.com/apache/zookeeper/pull/2299 for branch-3.8 Best, Kezhu Wang On Sat, Aug 16, 2025 at 12:03 AM Andor Molnar <an...@apache.org> wrote: > > Done. > > I’ve upgraded the loggers on branch-3.8 as suggested. > > https://github.com/apache/zookeeper/commit/1a316edd454f5123b4f6a5389c6887f015482c05 > > Let’s see how the build goes, but my plan is to put together a 3.8.5 release > today or early next week. > > Regards, > Andor > > > > > On Aug 15, 2025, at 10:39, Andor Molnar <an...@apache.org> wrote: > > > > Thanks Christopher. > > > >> But, if you are going to do a final 3.8 release, you might as well bump > >> logback/slf4j > >> just like the other branches > > > > > > That’s the key takeaway for me I think. Easiest thing to do with this is to > > backport the same upgrade patch that we did for master/3.9. I’ll do it on > > 3.8 as well. > > > > After 3.9.4 I’ll create a new 3.8.5 release anyways, because our rule is > > that we can only EoL a release line 6 months after making the next one > > stable. So, we should release 3.10.0 first, make 3.9 stable, announce that > > 3.8 will be EoL in 6 months. > > > > Thanks, > > Andor > > > > > > > > > >> On Aug 14, 2025, at 15:28, Christopher <ctubb...@apache.org> wrote: > >> > >> I provided some feedback on > >> https://github.com/apache/zookeeper/pull/2293 . Initially, I thought > >> the PR was for newer versions. I didn't realize it was intended for > >> 3.8, and most of my code review was assuming that it was for 3.10. I > >> really wouldn't bother changing this for 3.8. I think it's enough to > >> just advise users to upgrade to 3.9, and warn them about the potential > >> risks using the logging dependencies that ship with 3.8 so they can > >> apply their own mitigations, as needed. I don't even think it's > >> necessary to release another 3.8... just announce it as EOL without > >> any new/final 3.8 releases. 3.9 has been available for some time, and > >> is at least as stable as 3.8. Users should be upgrading to 3.9 instead > >> of continuing to update 3.8 versions. > >> > >> On Wed, Aug 13, 2025 at 10:44 PM 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, > >> > >> Except in the assemblies. It is still needed in at least > >> <scope>runtime</scope> to be included in an assembly. > >> > >>> - use “flatten-maven-plugin” to drop it from published pom (also drop the > >>> jar from release artifacts) > >> > >> I don't see the point of using flatten-maven-plugin. The dependency > >> entries in the POM only matter in two ways: > >> > >> 1. Dependencies can be included in downstream projects transitively. > >> This can be avoided by setting <optional>true</optional> or changing > >> the scope to <scope>test</scope>. Alternatively, downstream projects > >> can add `<exclusions>` entries for dependencies on zookeeper, or > >> override the version in their own <dependencyManagement> section. > >> Flattening the POM in ZK is not helpful for any of this. > >> 2. Dependencies in the POM are used to build the tarball/zip/fatjar > >> assemblies. You don't need to use flatten-maven-plugin to exclude > >> dependencies from an assembly. All plugins that create assemblies > >> already have their own means to exclude a dependency. > >> > >>> - 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 > >> > >> I don't think it's necessary to do another release of 3.8... I think > >> it can just be marked EOL without another release. But, if you are > >> going to do a final 3.8 release, you might as well bump logback/slf4j > >> just like the other branches. > >> > >>> > >>> 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 > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > >>> > > >
