Ok - based on what I'm hearing it sounds like starting with github: dependabot_alerts: true dependabot_updates: false
is our best bet. We can continue with the current process and address over time if there is interest. I created a tracking jira here: https://issues.apache.org/jira/browse/ZOOKEEPER-5034 PR here: https://github.com/apache/zookeeper/pull/2368 Patrick On Wed, Mar 25, 2026 at 10:44 AM Andor Molnár <[email protected]> wrote: > Yeah, all true. Everyone is correct. For instance, Curator has dropped > Jira completely. > They use GH Issues to track issues, GH Actions for CI, etc. We could adopt > their workflows > completely, I’m open to that, but tbh, reluctant working on it actively. > > Andor > > > > > > On Mar 25, 2026, at 12:28, Patrick Hunt <[email protected]> wrote: > > > > On Wed, Mar 25, 2026 at 10:04 AM Tamas Penzes <[email protected]> > wrote: > > > >> Just my two cents. > >> Christopher asked a great question: why should we depend on Jira for the > >> changelog? > >> e.g. Accumulo doesn't even use Jira and it's also an Apache project. So > >> there is a precedent. > >> So, this must not be an Apache rule requiring Jira tickets for changelog > >> creation, but rather an internal ZooKeeper rule that the PMC can change > by > >> decision. > >> I don't say that it should happen, I just say that it can happen. > Partially > >> (changing just how the changelog is generated) or totally (dropping the > use > >> of Jira). > >> In both cases, dependabot could be used without manual activity. > >> > >> > > I think everyone is correct? I believe Andor is highlighting the original > > plan (and still plan for ZK). Over the last few years Apache has become > > more open to other development methodologies and other projects adopted. > > > > One thing to note is that github and jira, etc... are all (?) reflected > in > > our mailing lists as every action in those systems triggers an email to > an > > Apache mailing list. (if not we could probably fix this) > > > > As such it seems like we could stay with our current process - as Andor > > mentioned our infra/processes all are codified in this - or we could > start > > making changes/move to "new", but that would mean additional work for > > someone both the code as well as the process level changes necessary. > > > > Regards, > > > > Patrick > > > > > >> Regards, > >> -- Tamaas > >> > >> > >> On Wed, Mar 25, 2026 at 2:59 PM Andor Molnár <[email protected]> wrote: > >> > >>> ZooKeeper currently relies on Jira tickets, because of multiple > reasons. > >>> One is that you mentioned, Release Notes are generated from Jira > tickets > >>> when creating a new release. Why have you used quotation marks? Aren't > >> that > >>> supposed to be real release notes? > >>> > >>> Other reason is that Apache’s general rule of thumb is that anything > >> which > >>> doesn’t happen in Jira or in the mailing lists, basically just doesn’t > >>> happen at all. Slack, Github, Discord, etc. are all very powerful tools > >> to > >>> aid development workflows, but at the end of the day you will have to > >> have > >>> a track record in an e-mail or in a Jira ticket to properly document > what > >>> has happened. I’m not sure if that Apache rule still stands, but > >>> ZooKeeper’s workflows have been tailored for the principle. > >>> > >>> So, to wrap up, yes, we’ll need separate Jira tickets for library > >> updates, > >>> otherwise the information will not be part of the release notes and get > >>> lost. > >>> > >>> Andor > >>> > >>> > >>>> On Mar 24, 2026, at 14:31, Christopher <[email protected]> wrote: > >>>> > >>>> In my experience, these aren't very frequent, and ZK already tries to > >>>> update frequently based on CVEs. Having dependabot automatically open > >>>> PRs helps the ZK project stay on top of these. It wouldn't add > >>>> noise... just replace the normal noise from updating them. > >>>> > >>>> My only real reluctance is that I don't know what ZK's normal merge > >>>> procedures are. Some projects require a separate JIRA ticket to be > >>>> created. Personally, I find this nonsensical, since the PR itself is > >>>> an issue ticket, and the JIRA ticket is just extra work. I prefer the > >>>> process of merging PRs, especially common sense automated PRs to > >>>> update a library, to be lightweight. However, others feel differently. > >>>> Sometimes those differences of opinion are based on other workflows > >>>> that could be improved (for example, using JIRA to automatically > >>>> generate a CHANGELOG, sometimes incorrectly called "release notes", > >>>> which could be replaced with a smaller, curated set of human-readable > >>>> release notes, and reliance on the git history for a detailed > >>>> CHANGELOG). > >>>> > >>>> If merging the automated PRs are lightweight, it's probably better > >>>> than the current process of manually creating PRs in response to the > >>>> alerts. If the process is more heavyweight, with a workflow that > >>>> relies on redundant JIRA issues, I can understand why there might be > >>>> opposition. > >>>> > >>>> Either way, I agree that experimentation is needed to determine the > >>>> best workflow. > >>>> > >>>> On Tue, Mar 24, 2026 at 11:52 AM Patrick Hunt <[email protected]> > >> wrote: > >>>>> > >>>>> I think they are ones here, likely also highlighted in the periodic > >>>>> security report that github sends. Hard to say though - the info > >> coming > >>> out > >>>>> of infra team - I'm not super clear. We might need to experiment a > >>> bit.... > >>>>> > >>>>> https://github.com/apache/zookeeper/security/dependabot > >>>>> > >>>>> Patrick > >>>>> > >>>>> > >>>>> On Tue, Mar 24, 2026 at 8:43 AM Andor Molnár <[email protected]> > >> wrote: > >>>>> > >>>>>> Thanks Pat for driving this effort. > >>>>>> > >>>>>> I would go with Patrick’s suggestion unless folks in the community > >> are > >>>>>> committed to monitor automatically created pull requests and action > >>> them > >>>>>> appropriately. I have some doubts regarding that and don’t want to > >> see > >>>>>> dozens of open pull requests in my notification list, so I kindly > >>> suggest > >>>>>> going with the alerts first and see how it goes. > >>>>>> > >>>>>> What kind of alerts are these? E-mail? > >>>>>> > >>>>>> Andor > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> On Mar 23, 2026, at 16:11, Christopher <[email protected]> > wrote: > >>>>>>> > >>>>>>> I think the automatic PRs are fine, personally, but I'm having > >> trouble > >>>>>>> understanding how these .asf.yaml settings map to the specific > >>>>>>> corresponding GitHub settings to know which options are best. I > >> think > >>>>>>> turning them both on are fine, and they can be tweaked later, if > >> they > >>>>>>> become a problem that need to be scaled back. > >>>>>>> > >>>>>>> On Mon, Mar 23, 2026 at 3:09 PM Patrick Hunt <[email protected]> > >>> wrote: > >>>>>>>> > >>>>>>>> According to the infra team we need to set the following in our > >>>>>> .asf.yaml: > >>>>>>>> https://github.com/apache/zookeeper/blob/master/.asf.yaml > >>>>>>>> > >>>>>>>> > >>>>>> > >>> > >> > https://github.com/apache/infrastructure-asfyaml/blob/main/README.md#depend_alerts > >>>>>>>> > >>>>>>>> github: > >>>>>>>> dependabot_alerts: true > >>>>>>>> dependabot_updates: false > >>>>>>>> > >>>>>>>> > >>>>>>>> I can submit a PR for this, assuming everyone here is good with > >> this > >>>>>> change? > >>>>>>>> > >>>>>>>> We want alerts but not the automatic security update pull requests > >>> is my > >>>>>>>> guess? (iow as doc'd here - alert true, update false) > >>>>>>>> > >>>>>>>> LMK if there are any concerns, regards, > >>>>>>>> > >>>>>>>> Patrick > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On Sat, Mar 21, 2026 at 10:32 AM Enrico Olivelli < > >>> [email protected]> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Il Ven 13 Mar 2026, 20:12 Patrick Hunt <[email protected]> ha > >>> scritto: > >>>>>>>>> > >>>>>>>>>> I see that we have scanning running in general: (says ran a few > >>> hours > >>>>>> ago) > >>>>>>>>>> https://github.com/apache/zookeeper/security/dependabot > >>>>>>>>>> > >>>>>>>>>> What I don't see is a PR workflow, here for hbase: > >>>>>>>>>> > >>>>>>>>>> > >>>>>> > >>> > >> > https://github.com/apache/hbase/actions/workflows/dependabot/dependabot-updates > >>>>>>>>>> which I don't seem to be able to add for ZK. > >>>>>>>>>> > >>>>>>>>>> I also see this: > >>>>>>>>>> > >>>>>>>>>> > >>>>>> > >>> > >> > https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-DependabotAlertsandUpdates > >>>>>>>>>> but hbase doesn't have it specified... > >>>>>>>>>> https://github.com/apache/hbase/blob/master/.asf.yaml > >>>>>>>>>> > >>>>>>>>>> I searched around quite a bit on infra JIRA and mail archives... > >>> but I > >>>>>>>>>> don't see any breadcrumbs. Weird. I guess I could ask on infra > >> ML? > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> Yes please > >>>>>>>>> > >>>>>>>>> Enrico > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Patrick > >>>>>>>>>> > >>>>>>>>>> On Thu, Mar 12, 2026 at 12:44 AM Dávid Paksy <[email protected] > > > >>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> Hi All, > >>>>>>>>>>> > >>>>>>>>>>> I think it is a great idea to use Dependabot and code scanning > >> in > >>>>>> GitHub. > >>>>>>>>>>> In the HBase project we already have Dependabot enabled and it > >>> helps > >>>>>> a > >>>>>>>>>>> lot > >>>>>>>>>>> with identifying issues and opening PR-s to fix them. > >>>>>>>>>>> Maybe we can ask in the ASF Infra Slack channel or open an > INFRA > >>> Jira > >>>>>>>>>>> ticket. > >>>>>>>>>>> > >>>>>>>>>>> Best Regards, > >>>>>>>>>>> Dávid > >>>>>>>>>>> > >>>>>>>>>>> Patrick Hunt <[email protected]> ezt írta (időpont: 2026. márc. > >>> 11., > >>>>>> Sze, > >>>>>>>>>>> 19:30): > >>>>>>>>>>> > >>>>>>>>>>>> On Tue, Mar 10, 2026 at 5:53 PM Christopher < > >> [email protected] > >>>> > >>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> You're looking at the GitHub Actions that can be added to a > >>>>>> project. > >>>>>>>>>>>>> I'm not even sure if INFRA would allow any of those to run. > >> They > >>>>>>>>>>>>> probably have an allow-list of GitHub Actions that can run on > >>> our > >>>>>>>>>>>>> repos. > >>>>>>>>>>>>> > >>>>>>>>>>>>> What I'm referring to would be in the repo settings: > >>>>>>>>>>>>> > >> https://github.com/apache/zookeeper/settings/security_analysis > >>>>>>>>>>>>> But, I don't have access to those settings for this repo (or > >> any > >>>>>> ASF > >>>>>>>>>>>>> repo; only INFRA has access). > >>>>>>>>>>>>> > >>>>>>>>>>>>> There may be a .asf.yaml option to enable the automated > >>> dependabot > >>>>>>>>>>> PRs. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> Hm. How would I find out more about this? > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks! > >>>>>>>>>>>> > >>>>>>>>>>>> Patrick > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> On Tue, Mar 10, 2026 at 4:38 PM Patrick Hunt < > >> [email protected]> > >>>>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Tue, Mar 10, 2026 at 12:28 PM Christopher < > >>> [email protected] > >>>>>>> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I think it's probably sufficient to just enable the GitHub > >>> code > >>>>>>>>>>>>>>> scanning and dependabot PRs. That's what other projects do. > >>> It's > >>>>>>>>>>>>>>> pretty easy to review and merge right from the interface, > >> and > >>> it > >>>>>>>>>>>> helps > >>>>>>>>>>>>>>> stay on top of these. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Sounds reasonable. Which code scanner do they use? when I > >>> attempt > >>>>>>>>>>> to > >>>>>>>>>>>> turn > >>>>>>>>>>>>>> code scanning on it gives me a list of options. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I also noticed that osv-scanner is an option: > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>> > >>> > >> > https://github.com/apache/zookeeper/actions/new?category=security&query=osv > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Patrick > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Tue, Mar 10, 2026 at 3:08 PM Patrick Hunt < > >>> [email protected]> > >>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Tue, Mar 10, 2026 at 10:18 AM Patrick Hunt < > >>>>>>>>>>> [email protected]> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On Mon, Mar 9, 2026 at 2:08 PM Patrick Hunt < > >>>>>>>>>>> [email protected]> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> On Mon, Mar 9, 2026 at 2:02 PM Enrico Olivelli < > >>>>>>>>>>>>> [email protected]> > >>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Il Lun 9 Mar 2026, 17:27 Patrick Hunt < > [email protected] > >>> > >>>>>>>>>>> ha > >>>>>>>>>>>>> scritto: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> I noticed that there are GHSA reports which don't > >> always > >>>>>>>>>>> have > >>>>>>>>>>>>> CVEs > >>>>>>>>>>>>>>>>>>>> assigned. We have the OWASP scanner scanning for CVEs > >> as > >>>>>>>>>>> part > >>>>>>>>>>>>> of > >>>>>>>>>>>>>>> our > >>>>>>>>>>>>>>>>>>>> Jenkins infra, however not GHSA. Should we add this? > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> There's a tool "osv-scanner" which I ran locally on my > >>>>>>>>>>>> machine > >>>>>>>>>>>>> (not > >>>>>>>>>>>>>>>>>>> sure if > >>>>>>>>>>>>>>>>>>>> this is running right but ...), it reported the > >>>>>>>>>>> following for > >>>>>>>>>>>>>>> trunk.... > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Is it possible to run it on Github actions, instead of > >>>>>>>>>>> Jenkins? > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> In any case I am +1 to add new popular scanners, > because > >>>>>>>>>>> having > >>>>>>>>>>>>> their > >>>>>>>>>>>>>>>>>>> reports can help us see the problems as soon as they > hit > >>>>>>>>>>> users > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> I notice we don't have github.com native security > >> scanning > >>>>>>>>>>>>> active, > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Code scanning alerts • Needs setup > >>>>>>>>>>>>>>>>>>> Automatically detect common vulnerability and coding > >>> errors > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> perhaps that would be sufficient? Maybe we should try > >> that > >>>>>>>>>>>> first? > >>>>>>>>>>>>>>> Anyone > >>>>>>>>>>>>>>>>>> know why we are not using it?/any reason not to just > turn > >>>>>>>>>>> it on? > >>>>>>>>>>>>> Any > >>>>>>>>>>>>>>> reason > >>>>>>>>>>>>>>>>>> not to turn it on? > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> What's our policy - if dependabot submits a PR, is that > >>>>>>>>>>>> something a > >>>>>>>>>>>>>>>>> committer can "+1" and commit? (I assume yes?) Via the > >>>>>>>>>>> github PR > >>>>>>>>>>>>>>> process? > >>>>>>>>>>>>>>>>> (eg merge/commit/close via the github UI) > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I can also try this if there are no objections and seems > to > >>>>>>>>>>> align > >>>>>>>>>>>>> with > >>>>>>>>>>>>>>> your > >>>>>>>>>>>>>>>> feedback @Enrico Olivelli <[email protected]> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> https://google.github.io/osv-scanner/github-action/ > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> OSV-Scanner is available as a CI/CD Action. We currently > >>> offer > >>>>>>>>>>> two > >>>>>>>>>>>>>>>> different reusable workflows for Github: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> A workflow that triggers a scan with each pull request and > >>> will > >>>>>>>>>>>> only > >>>>>>>>>>>>>>> report > >>>>>>>>>>>>>>>> new vulnerabilities introduced through the pull request. > >>>>>>>>>>>>>>>> A workflow that performs a full vulnerability scan, which > >> can > >>>>>>>>>>> be > >>>>>>>>>>>>>>> configured > >>>>>>>>>>>>>>>> to scan on pushes or a regular schedule. The full > >>> vulnerability > >>>>>>>>>>>> scan > >>>>>>>>>>>>> can > >>>>>>>>>>>>>>>> also be configured to run on release to prevent releasing > >>> with > >>>>>>>>>>>> known > >>>>>>>>>>>>>>>> vulnerabilities in dependencies. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Patrick > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Patrick > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Enrico > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Patrick > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> ..... <clip general logs> .... > >>>>>>>>>>>>>>>>>>>> End status: 536 dirs visited, 2308 inodes visited, 21 > >>>>>>>>>>> Extract > >>>>>>>>>>>>>>> calls, > >>>>>>>>>>>>>>>>>>>> 3.877381125s elapsed, 3.877341s wall time > >>>>>>>>>>>>>>>>>>>> Filtered 3 local/unscannable package/s from the scan. > >>>>>>>>>>>>>>>>>>>> Total 5 packages affected by 10 known vulnerabilities > >> (0 > >>>>>>>>>>>>> Critical, > >>>>>>>>>>>>>>> 3 > >>>>>>>>>>>>>>>>>>> High, > >>>>>>>>>>>>>>>>>>>> 4 Medium, 3 Low, 0 Unknown) from 1 ecosystem. > >>>>>>>>>>>>>>>>>>>> 10 vulnerabilities can be fixed. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>> > >>> > >> > ╭─────────────────────────────────────┬──────┬───────────┬───────────────────────────────────────┬─────────┬───────────────┬──────────────────────────────────────────────────────╮ > >>>>>>>>>>>>>>>>>>>> │ OSV URL │ CVSS │ > >> ECOSYSTEM > >>>>>>>>>>> │ > >>>>>>>>>>>>> PACKAGE > >>>>>>>>>>>>>>>>>>>> │ VERSION │ FIXED VERSION │ SOURCE > >>>>>>>>>>>>>>>>>>>> │ > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>> > >>> > >> > ├─────────────────────────────────────┼──────┼───────────┼───────────────────────────────────────┼─────────┼───────────────┼──────────────────────────────────────────────────────┤ > >>>>>>>>>>>>>>>>>>>> │ https://osv.dev/GHSA-25qh-j22f-pwp8 │ 5.9 │ Maven > >>>>>>>>>>> │ > >>>>>>>>>>>>>>>>>>>> ch.qos.logback:logback-core │ 1.3.15 │ > >> 1.3.16 > >>>>>>>>>>>>> │ > >>>>>>>>>>>>>>>>>>>> zookeeper-contrib/zookeeper-contrib-fatjar/pom.xml │ > >>>>>>>>>>>>>>>>>>>> │ https://osv.dev/GHSA-qqpg-mvqg-649v │ 1.8 │ Maven > >>>>>>>>>>> │ > >>>>>>>>>>>>>>>>>>>> ch.qos.logback:logback-core │ 1.3.15 │ > >> 1.5.25 > >>>>>>>>>>>>> │ > >>>>>>>>>>>>>>>>>>>> zookeeper-contrib/zookeeper-contrib-fatjar/pom.xml │ > >>>>>>>>>>>>>>>>>>>> │ https://osv.dev/GHSA-25qh-j22f-pwp8 │ 5.9 │ Maven > >>>>>>>>>>> │ > >>>>>>>>>>>>>>>>>>>> ch.qos.logback:logback-core │ 1.3.15 │ > >> 1.3.16 > >>>>>>>>>>>>> │ > >>>>>>>>>>>>>>>>>>>> zookeeper-contrib/zookeeper-contrib-loggraph/pom.xml │ > >>>>>>>>>>>>>>>>>>>> │ https://osv.dev/GHSA-qqpg-mvqg-649v │ 1.8 │ Maven > >>>>>>>>>>> │ > >>>>>>>>>>>>>>>>>>>> ch.qos.logback:logback-core │ 1.3.15 │ > >> 1.5.25 > >>>>>>>>>>>>> │ > >>>>>>>>>>>>>>>>>>>> zookeeper-contrib/zookeeper-contrib-loggraph/pom.xml │ > >>>>>>>>>>>>>>>>>>>> │ https://osv.dev/GHSA-25qh-j22f-pwp8 │ 5.9 │ Maven > >>>>>>>>>>> │ > >>>>>>>>>>>>>>>>>>>> ch.qos.logback:logback-core │ 1.3.15 │ > >> 1.3.16 > >>>>>>>>>>>>> │ > >>>>>>>>>>>>>>>>>>>> zookeeper-contrib/zookeeper-contrib-rest/pom.xml │ > >>>>>>>>>>>>>>>>>>>> │ https://osv.dev/GHSA-qqpg-mvqg-649v │ 1.8 │ Maven > >>>>>>>>>>> │ > >>>>>>>>>>>>>>>>>>>> ch.qos.logback:logback-core │ 1.3.15 │ > >> 1.5.25 > >>>>>>>>>>>>> │ > >>>>>>>>>>>>>>>>>>>> zookeeper-contrib/zookeeper-contrib-rest/pom.xml │ > >>>>>>>>>>>>>>>>>>>> │ https://osv.dev/GHSA-cfxw-4h78-h7fw │ 8.9 │ Maven > >>>>>>>>>>> │ > >>>>>>>>>>>>>>>>>>> dnsjava:dnsjava > >>>>>>>>>>>>>>>>>>>> │ 3.5.1 │ 3.6.0 │ > >>>>>>>>>>>>>>>>>>> zookeeper-server/pom.xml > >>>>>>>>>>>>>>>>>>>> │ > >>>>>>>>>>>>>>>>>>>> │ https://osv.dev/GHSA-crjg-w57m-rqqf │ 7.7 │ Maven > >>>>>>>>>>> │ > >>>>>>>>>>>>>>>>>>> dnsjava:dnsjava > >>>>>>>>>>>>>>>>>>>> │ 3.5.1 │ 3.6.0 │ > >>>>>>>>>>>>>>>>>>> zookeeper-server/pom.xml > >>>>>>>>>>>>>>>>>>>> │ > >>>>>>>>>>>>>>>>>>>> │ https://osv.dev/GHSA-mmwx-rj87-vfgr │ 7.1 │ Maven > >>>>>>>>>>> │ > >>>>>>>>>>>>>>>>>>> dnsjava:dnsjava > >>>>>>>>>>>>>>>>>>>> │ 3.5.1 │ 3.6.0 │ > >>>>>>>>>>>>>>>>>>> zookeeper-server/pom.xml > >>>>>>>>>>>>>>>>>>>> │ > >>>>>>>>>>>>>>>>>>>> │ https://osv.dev/GHSA-4cx2-fc23-5wg6 │ 6.3 │ Maven > >>>>>>>>>>> │ > >>>>>>>>>>>>>>>>>>>> org.bouncycastle:bcpkix-jdk18on (dev) │ 1.78 │ 1.79 > >>>>>>>>>>>>> │ > >>>>>>>>>>>>>>>>>>>> zookeeper-server/pom.xml │ > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>> > >>> > >> > ╰─────────────────────────────────────┴──────┴───────────┴───────────────────────────────────────┴─────────┴───────────────┴──────────────────────────────────────────────────────╯ > > >
