[jira] [Created] (ZOOKEEPER-4484) Security Vulnerabilities in Apache Zookeper image
Debanjan Bhowmick created ZOOKEEPER-4484: Summary: Security Vulnerabilities in Apache Zookeper image Key: ZOOKEEPER-4484 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4484 Project: ZooKeeper Issue Type: Bug Affects Versions: 3.7.0 Reporter: Debanjan Bhowmick Attachments: 0-02-03-43ecbd3105b8acb3dabd52683aac076b818c698c721c89070024677252b5a017_1c6da8c1746854.png We have found this below list of CRITICAL Security vulnerabilties present in the official zookeper image - ||Vulnerability ID||Component||Infected versions||Fixed versions|| |CVE-2021-33574|debian:bullseye:libc6:2.31-13+deb11u2|N/A|N/A| |XRAY-179837|io.netty:netty-codec:4.1.59.Final|< 4.1.66.Final|4.1.66.Final| |CVE-2022-23307|log4j:log4j:1.2.17|All Versions|N/A| |CVE-2019-17571|log4j:log4j:1.2.17|≤ 1.2.17|N/A| |CVE-2022-23305|log4j:log4j:1.2.17|1.1.0 ≤ Version ≤ 1.2.17|N/A| |CVE-2022-23219|debian:bullseye:libc6:2.31-13+deb11u2|N/A|N/A| |CVE-2022-23218|debian:bullseye:libc6:2.31-13+deb11u2|N/A|N/A| Can you please help us with the fix or update us on the release of security patches and also their respective timelines. -- This message was sent by Atlassian Jira (v8.20.1#820001)
Re: Can we add the "readonly" field in ConnectRequest？
> if there is a way to detect ...
I think it's possible but losing the purpose we merge the readonly field.
For example, we can still catch an exception and go into another code path,
but in any approach we detect a different version of client, the only
difference
of these two protocol is about how to write connect {request|response}. And
thus we actually do something as we do now.
But if we can factor out a protocol interface it may be worth to give it a
try,
as if we still want to continue ZOOKEEPER-102, there will be such a protocol
interface and switch abstraction.
Best,
tison.
Enrico Olivelli 于2022年3月2日周三 00:07写道：
> Il giorno mar 1 mar 2022 alle ore 16:32 tison ha
> scritto:
> >
> > ... and this is the main PR:
> https://github.com/apache/zookeeper/pull/1832
> >
> > However, it seems that ZK 3.3.x may be broken and the jute protocol
> cannot
> > cover the case. You can review the PR and I already commented details.
>
> I have seen the patch. Good work!
>
> I wonder if there is a way to detect that we are talking with a old
> client and use a different version of the protocol.
>
> Dropping compatibility to 3.3 is not so bad, I assume that most of the
> users are on 3.4+ currently
>
> That said, if we can still be compatible it will be far better,
> ZooKeeper has a strong tradition of being compatible and we should
> break this only if strictly needed,
> that is the benefit of breaking compatibility is bigger than the pain
>
> Enrico
>
>
> >
> > Best,
> > tison.
> >
> >
> > tison 于2022年2月28日周一 09:33写道：
> >
> > > Hi,
> > >
> > > Thanks for eolivelli's review and approval, this PR[1] is waiting for
> > > another reviewer to proceed. I'd like to bump this thread to see if any
> > > committer could help on reviewing :)
> > >
> > > Best,
> > > tison.
> > >
> > > [1] https://github.com/apache/zookeeper/pull/1826
> > >
> > >
> > > Enrico Olivelli 于2022年2月24日周四 23:20写道：
> > >
> > >> Tison
> > >>
> > >> Il Gio 24 Feb 2022, 15:29 tison ha scritto:
> > >>
> > >> > Here is an initial PR[1] you can give a review. I think the script
> is
> > >> > enough for the original purpose merging readOnly field.
> > >> >
> > >>
> > >> Very good
> > >> I left one comment
> > >>
> > >>
> > >>
> > >> Enrico
> > >>
> > >>
> > >>
> > >> > Best,
> > >> > tison.
> > >> >
> > >> > [1] https://github.com/apache/zookeeper/pull/1826
> > >> >
> > >> >
> > >> > Enrico Olivelli 于2022年2月23日周三 20:46写道：
> > >> >
> > >> > > Il Mer 23 Feb 2022, 10:46 tison ha
> scritto:
> > >> > >
> > >> > > > Hi Enrico,
> > >> > > >
> > >> > > > Thanks for your reply! Do we have end to end tests for the same
> > >> version
> > >> > > of
> > >> > > > client and server now?
> > >> > > >
> > >> > >
> > >> > > We haven't.
> > >> > > We only use the local code to run both the client and the server
> > >> > >
> > >> > > Enrico
> > >> > >
> > >> > >
> > >> > > If we already have such tests, then wrapping them among different
> > >> > versions
> > >> > > > is possible. Otherwise,
> > >> > > > we may add such end to end tests first XD
> > >> > > >
> > >> > > > Best,
> > >> > > > tison.
> > >> > > >
> > >> > > >
> > >> > > > Enrico Olivelli 于2022年2月22日周二 02:14写道：
> > >> > > >
> > >> > > > > I missed this thread.
> > >> > > > > If you manage to keep full compatibility with old clients
> then I
> > >> am
> > >> > +1
> > >> > > > >
> > >> > > > > We are missing compatibility tests, it may be a good time to
> start
> > >> > such
> > >> > > > > suite.
> > >> > > > > We can start by running the client (bash cli) in a docker
> > >> container
> > >> > > > > probably.
> > >> > > > >
> > >> > > > >
> > >> > > > > Enrico
> > >> > > > >
> > >> > > > > Il Lun 21 Feb 2022, 17:47 tison ha
> > >> scritto:
> > >> > > > >
> > >> > > > > > Bump the thread for one last try to see if any zookeeper is
> > >> > > interested
> > >> > > > in
> > >> > > > > > this topic.
> > >> > > > > >
> > >> > > > > > Best,
> > >> > > > > > tison.
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
>
Re: Moving 3.5 to EOL
Hi folks, I’ve created a pull request for the website change: https://github.com/apache/zookeeper/pull/1834 Once the website is updated, I’ll make the announcement for 3.5 EoL. Thanks, Andor > On 2022. Feb 17., at 16:54, Szalay-Bekő Máté > wrote: > > Thanks for the clarification, I like the plan! > >> having 2 active versions (stable and current) and when a new minor > version is announced, the least recent will get another 6 months of support > > What does this mean exactly? Just to be on the same page, this is what you > propose if we release 3.8.0 until let's say end of February 2022? > - 3.5 EoL 1st of June 2022 > - 3.6 EoL 1st of Sept 2022 (~6 months after 3.8.0 release) > - 3.7 will become "stable" > - 3.8 will become "current" > > Did anyone in the community test the latest 3.7 (which is still 3.7.0) with > large clusters in production? Are we confident saying 3.7 is stable? > (on the other hand, if we don't do the announcement, most likely people > won't start to migrate to 3.7) > > Mate > > On Wed, Feb 16, 2022 at 1:33 PM Enrico Olivelli wrote: > >> Andor, >> >> Il Mer 16 Feb 2022, 12:47 Andor Molnar ha scritto: >> >>> Okay, I agree that keeping 2 active versions rather than tying ourselves >>> to some fixed deadlines makes more sense for ZooKeeper. Let’s go with >> this >>> approach then if there’s no other objections: >>> >>> 1) Add this information to the Releases web page: I’ll describe that >>> ZooKeeper is having 2 active versions (stable and current) and when a new >>> minor version is announced, the least recent will get another 6 months of >>> support (security and bugfixes), but after that it will become EoL. That >>> means no further releases are expected from the community and users >> should >>> follow the supported upgrade path. I’ll send this out for review soon. >>> >> >> +1 >> >> >>> 2) Announce 3.5 EoL 1st of June 2022. (sorry Enrico, the end of the long >>> discussion is essentially what you originally proposed) >>> >> >> +1 >> Thanks >> >> >> Enrico >> >> >> >>> Please let me know if you have concerns with this path. >>> >>> Andor >>> >>> >>> On 2022. Feb 14., at 17:07, Patrick Hunt wrote: "Define what EOL means" - whatever we do let's make sure it gets onto >> the "releases" page so that folks have official information they can >>> reference from the project. I like having a max of 2 versions. Stable and current. I agree that due >>> to our lack of communication/policy so far we should ensure that people >> have opportunity to move/support on the release versions (3.x minors) we >>> current support. I like the idea of tying old releases to new ones. I don't think tying ourselves to a specific, long term is good though. It definitely >> reduces flexibility. Same with saying that new minors are going to be released every Y time. Can't we just say that a stable release will be supported >>> for a minimum of 6 months (other timeframe?) after moving the stable >>> indicator from 3.x to 3.x+1. We then have the flexibility to keep it around >> longer >>> if there is a reason why folks want to stick for a longer time (eg major changes in the more recent versions) Patrick On Fri, Feb 11, 2022 at 8:08 AM Christopher >> wrote: > Regarding the suggestion: "Maybe we can also communicate that we’re >>> going > to officially EoL the least recent ZK version every 2 years." If you > release new versions less frequently than that, the number of >>> maintenance > versions will go to 0 (though, in practice, you wouldn't EOL your >>> current > release). If you release more frequently, you'll be stuck maintaining >> an > increasing number of versions. > > To keep the maintenance burden relatively consistent, I suggest tying >>> your > EOL schedule to your release schedule, so when you release a new >>> version, > you drop the oldest one. If you release every 2 years, then it works >> out > the same. But if you release more or less often, your maintenance >> burden > stays consistent. > > I would start by deciding the minimum number of concurrent versions >> you > want to maintain. I suggest no more than 2, but ZK currently has 3, >> and >>> is > about to be 4 soon. If you're not marking specific versions as >> long-term > stable, then the default would be to assume you're maintaining the >> most > recent versions. > > Then, consider churn. If you release frequently, you may want to set a > minimum age for maintenance, so users aren't forced to upgrade too >>> often. > So, if you start with 2 concurrent versions and you have a few >> versions > released rapidly, you may temporarily need to support up to 3 or 4 >>> releases > until the oldest ones reach the minimum age, like 2 years for example, >>> and > are able to be EOL'd. >
