The only thing open is doing the release: https://opennlp.apache.org/release.html
Feel free to run your first one :) > Am 17.06.2026 um 16:18 schrieb Atita Arora <[email protected]>: > > If it helps , I can try to help as I have seen a bit of both codebases. > What are the next steps? > > > On Wed, 17 Jun 2026, 15:02 Eric Pugh, <[email protected]> > wrote: > >> I just created three VEX files for these three vulnerabilities for the >> Solr website: https://github.com/apache/solr-site/pull/192 >> >> I’ll update the mitigation steps once 1.9.5 comes out! >> >> >> >>> On Jun 12, 2026, at 11:31 AM, Eric Pugh <[email protected]> >> wrote: >>> >>> Just looked at the branch, and thank you for doing the back port! >> Looking at the code, it would have taken me a week of work just do those >> back ports! >>> >>>> On Jun 12, 2026, at 10:52 AM, Richard Zowalla <[email protected]> wrote: >>>> >>>> So Martin merged all the stuff to 1.x - any volunteer to run the >> release? >>>> >>>>> Am 12.06.2026 um 16:24 schrieb Richard Zowalla <[email protected]>: >>>>> >>>>> 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 <http://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 >>> >>>>>>>>>>> <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> < >>>>>>>>>>> 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> < >>>>>>>>>>> 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. >>>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >> >> 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. >>
