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