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