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