Porting file-handling enhancements from main

[bdeboe]

Reposting UIMA-6486 (JIRA is no longer used)

Hi,

we distribute a custom annotator built on UIMA v2, which is affected by https://nvd.nist.gov/vuln/detail/CVE-2022-32287. We do not have any near-term bandwidth to upgrade our library to v3, and more critically some of our customers have other pipelines still running on v2 that they may not be able to migrate to v3 any time soon.

Are there any plans to deliver a new v2.11 bugfix release that addresses this vulnerability?

Thanks!

It appears to have been addressed for the main v3 branch through PRs #209 and #211

@reckart already responded v2 is no longer maintained. While I think I should be able to pick up the required changes and move them to main-v2, but not sure how much further I'd be able to take that.

[reckart]

I'll be happy to vote on a release, but I do not have the spare resources to run another release of the v2 branch.

So if anybody wants to do that and take over responsibility for the v2 branch, I'll be happy to support the person getting the necessary committer status to do releases.

[bdeboe]

are there any UIMA committers that also work on / with Apache cTAKES? cTAKES still uses UIMA v2 and I imagine converting all of that to use UIMA v3 would be a very significant project.

Again, we're happy to contribute to the actual bugfix, but don't have the experience for driving a full release, I'm afraid....

[reckart]

are there any UIMA committers that also work on / with Apache cTAKES?

Not that I am aware of. Personally, I do occasionally have a look at cTAKES and try providing helpful advices (@seanfinan), but I do not contribute code.

Also, cTAKES might currently be blocked from going to v3 because I believe they use ClearTK which is not yet available for v3. Once I am done with the UIMA/uimaFIT 3.4.0 releases, I plan to do a ClearTK release against v3 (the code on the main branch has already been updated).

[reckart]

I imagine converting all of that to use UIMA v3 would be a very significant project.

Actually, converting a project from v2 to v3 shouldn't be too much effort. The main effort is re-generating any JCas classes for type systems. Upgrading uimaFIT from v2 to v3 is slightly more effort, in particular if the code uses the ExternalResourceFactory as some methods have been renamed here - but otherwise that should also be pretty straightforward.

[reckart]

Again, we're happy to contribute to the actual bugfix, but don't have the experience for driving a full release, I'm afraid....

The fix is trivial, but the v2 release would cost me probably at least a day of work.

[reckart]

This issue contains the release checklist for UIMA 2.11.0 in case you are interested: https://issues.apache.org/jira/browse/UIMA-6328?jql=project%20%3D%20UIMA%20AND%20text%20~%20release

[reckart]

Also, there might be a few additional issues to be backported in case somebody wants to resurrect v2 - not 100% sure if v2 is affected by these, but if it is, a backport would be useful.

• UIMA Log4jLogger_impl not compatible with log4j 2.18.0+ #267
• Unable to install UIMA 3.3.1 Eclipse Plugins in Eclipse 2022-09 #266

[bdeboe]

Perhaps a little crude, but the easy way out for v2 is now in PR #294

• UIMA Log4jLogger_impl not compatible with log4j 2.18.0+ #267

This isn't applicable as UIMA v2 is still on log4j 1.*, afaics. That migration would be a sizeable project all in itself.

• Unable to install UIMA 3.3.1 Eclipse Plugins in Eclipse 2022-09 #266

I wonder if this one would be worth it (however innocent it looks). It probably feels like I'm dodging work, but my intent is not to promote people to continue developing in UIMA v2, but rather to unblock a customer that's stuck there with an existing application.

I can take a shot at that release checklist if the PR for this FileUtil change is considered viable