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 >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>> >
