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