Nice!
> Am 18.06.2026 um 16:31 schrieb Atita Arora <[email protected]>:
>
> Sure , taking a first stab at it !
> Will reach out on slack if I get stuck, Thanks !
>
> On Wed, Jun 17, 2026 at 7:56 PM Richard Zowalla <[email protected]> wrote:
>
>> 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.
>>>>
>>
>>
