Everything in question should now either be on opennlp-1.x branch or open as a PR ;-)
> Am 12.06.2026 um 15:59 schrieb Martin Wiesner <[email protected]>: > > Hi all, > > I’ve just pushed a new 'opennlp-1.x‘ maintenance branch. It contains most of > the (transient) dep updates as identified by Richard, see below. > Moreover, it has a fix for OPENNLP-1826 which I could easily cherry-pick from > 2.x maintenance branch. > > Rn, 1819, 1820 and 1821 require a deeper look and more work to be integrated. > The delta is just to big to for easy cherries here. > > @ #3: Yes - should be conducted by PMC members. > @ #4: I’d like to add, we should declare 1.x EOL, once and if we get an 1.9.5 > (last) release out. > > Best > Martin > >> Am 12.06.2026 um 15:15 schrieb Richard Zowalla <[email protected]>: >> >> From what I can see after c88f57814c0af0dccf471b895a35981ecdac2e7a - the >> work would be >> >> 1. Cherry pick or port the CVE fixes from 2.x into that branch. This would >> be (according to Martin - thx btw): OPENNLP-1819, 1820, 1821 and 1826 (best >> case) >> 2. Fix the transient CVEs (all in brat annotator) >> >> Dependency: com.fasterxml.jackson.core:jackson-databind >> Current: 2.10.1 >> Issue: Long list of deserialization/DoS CVEs: CVE-2020-25649 (XXE), >> CVE-2020-36179/36180/36181/36182 + 2021-20190 >> (polymorphic >> deser gadgets), CVE-2022-42003 / CVE-2022-42004 (DoS) >> Fix to: ≥ 2.12.7.1 (min) — better a current 2.18.x >> ──────────────────────────────────────── >> Dependency: jackson-core / jackson-annotations >> Current: 2.10.1 >> Issue: Keep in lockstep with databind (BOM) >> Fix to: same train as databind >> ──────────────────────────────────────── >> Dependency: org.glassfish.jersey.* (common, client, server, >> container-grizzly2, media-json-jackson, media-jaxb, >> entity-filtering) >> Current: 2.30.1 >> Issue: CVE-2021-28168 — local info disclosure via world‑readable temp file >> in jersey-common (affects 2.28–2.33) >> Fix to: ≥ 2.34; for Java‑8 safety use 2.35 >> ──────────────────────────────────────── >> Dependency: org.glassfish.grizzly:grizzly-http-server / -http / -framework >> Current: 2.4.4 (2018) >> Issue: No single high CVE pinned to 2.4.4, but very stale; HTTP >> request-smuggling hardening landed in later 2.4.x. Pulled in >> transitively by Jersey >> Fix to: comes free when Jersey is bumped (2.35 → grizzly 2.4.4 still; 2.40+ >> ships newer grizzly) >> >> 3. After a release: Talk with ASF Security to alter the published CVEs to >> include the new release as fix version (as I guess this effort is mostly >> driven by static CVE scanners blaming openlp right now). >> 4. Decide in OpenNLP if and how many release lines we are willing to handle >> as a PMC. >> >> Gruß >> Richard >> >>> Am 09.06.2026 um 22:00 schrieb Richard Zowalla <[email protected]>: >>> >>> As written: I dont mind if we do a release (as long as I am not the person >>> doing it). >>> Aisde from the back ports, it might also need dependency updates as well >>> >>>> Am 09.06.2026 um 14:42 schrieb Jeff Zemerick <[email protected]>: >>>> >>>> Yes, thanks Eric and Suneel - Lucene/Solr 9. >>>> >>>> Thanks, >>>> Jeff >>>> >>>> >>>> >>>> On Mon, Jun 8, 2026 at 11:54 AM Suneel Marthi <[email protected]> wrote: >>>>> >>>>> concur with Eric - it's {Lucene, Solr} - 9x. >>>>> >>>>> >>>>> >>>>> >>>>> सोम, 8 जून 2026 को 11:19 am बजे को Eric Pugh < >>>>> [email protected]> ने लिखा: >>>>> >>>>>> I think Jeff meant to say Lucene 9 (and Solr 9)! >>>>>> >>>>>> >>>>>> >>>>>>> On Jun 8, 2026, at 10:40 AM, Richard Zowalla <[email protected]> >>>>>> wrote: >>>>>>> >>>>>>> No, OpenNLP is used in Lucene. >>>>>>> >>>>>>>> Am 08.06.2026 um 16:29 schrieb Suneel Marthi <[email protected] >>>>>>> : >>>>>>>> >>>>>>>> Do we now have a Lucene/Solr dependency in OpenNLP ? or am I reading >>>>>>>> this wrong? >>>>>>>> >>>>>>>> सोम, 8 जून 2026 को 10:26 am बजे को Richard Zowalla <[email protected]> >>>>>> ने >>>>>>>> लिखा: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> This page lists Lucene 8 as EOL: https://endoflife.date/apache-lucene >>>>>> <https://endoflife.date/apache-lucene> >>>>>>>>> >>>>>>>>> And what I found here from SOLR is: >>>>>>>>> >>>>>>>>> "With Lucene 10 having been released, and therefore Lucene 8 reaching >>>>>> EOL, >>>>>>>>> the Apache Lucene and Solr PMCs are no longer able to provide new >>>>>> releases >>>>>>>>> for Solr 8. Solr 8.11.4 will be the last release of Solr 8.“ >>>>>>>>> Cf. https://solr.apache.org/news.html#solr-8-reaches-end-of-life < >>>>>> https://solr.apache.org/news.html#solr-8-reaches-end-of-life> >>>>>>>>> >>>>>>>>> Couldn’t find any authoritative source from the Lucene PMC regarding >>>>>> only >>>>>>>>> maintaining 2 release lines, but the Solr posted the above. >>>>>>>>> >>>>>>>>> In general: No objections from my side, but the last 8.11.x release of >>>>>>>>> Lucene was done 2 years ago - so IMHO there should be a clear release >>>>>> plan >>>>>>>>> on their side, if we make the extra round-trip... >>>>>>>>> >>>>>>>>> Gruß >>>>>>>>> Richard >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> Am 08.06.2026 um 14:43 schrieb Jeff Zemerick <[email protected] >>>>>>> : >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> About a month ago we had a few CVEs get addressed. (Thanks to those >>>>>>>>>> who took care of them.) Those fixes went into the 2.x branch and for >>>>>>>>>> 3.0. >>>>>>>>>> >>>>>>>>>> At least one of those CVEs affects 1.9.x. Normally, I don't think I >>>>>>>>>> would worry about it, but in this case, Apache Lucene depends on >>>>>>>>>> 1.9.x, and Lucene is still doing releases on that version (8.11), >>>>>>>>>> which is used by Solr 8. >>>>>>>>>> >>>>>>>>>> What are everyone's thoughts on doing a 1.9.5 release to address, in >>>>>>>>>> particular, OPENNLP-1820 >>>>>>>>>> (https://issues.apache.org/jira/browse/OPENNLP-1820 < >>>>>> https://issues.apache.org/jira/browse/OPENNLP-1820>) and then making a >>>>>>>>>> PR to get 1.9.5 into Lucene (and then downstream into Solr)? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Jeff >>>>>>>>> >>>>>>>>> >>>>>> >>>>>> Disclaimer >>>>>> >>>>>> The information contained in this communication from the sender is >>>>>> confidential. It is intended solely for use by the recipient and others >>>>>> authorized to receive it. If you are not the recipient, you are hereby >>>>>> notified that any disclosure, copying, distribution or taking action in >>>>>> relation of the contents of this information is strictly prohibited and >>>>>> may >>>>>> be unlawful. >>>>>> >>>>>> This email has been scanned for viruses and malware, and may have been >>>>>> automatically archived by Mimecast, a leader in email security and cyber >>>>>> resilience. Mimecast integrates email defenses with brand protection, >>>>>> security awareness training, web security, compliance and other essential >>>>>> capabilities. Mimecast helps protect large and small organizations from >>>>>> malicious activity, human error and technology failure; and to lead the >>>>>> movement toward building a more resilient world. To find out more, visit >>>>>> our website. >>>>>> >>> >> >
