Fix CVE-2025-66516: Upgrade to Solr 9.10 with external Tika server

[reekitconcept]

Summary

• Upgrade Solr from 8 to 9.10
• Add external Tika server (3.2.3) to mitigate critical CVE-2025-66516 (CVSS 10.0)
• Update solrconfig.xml for Solr 9 compatibility
• Add Makefile targets for solr-activate-and-reindex
• Add upgrade documentation for users explaining migration steps

Security

This PR addresses CVE-2025-66516, a critical XXE vulnerability in Apache Tika (CVSS 10.0) affecting tika-core versions 1.13-3.2.1. The fix uses an external Tika server with version 3.2.3 which includes the patched tika-core.

Documentation

Added docs/docs/how-to-guides/upgrade-cve-2025-66516.md explaining the upgrade steps:

• Users on vanilla kitconcept.solr image: No configuration changes required, just pull the new image
• Users with custom Solr images: Key configuration changes documented (Solr 9.x, SOLR_MODULES, external Tika)

Test plan

• Verify Solr starts correctly with new configuration
• Verify Tika server is accessible
• Test document extraction/indexing works with external Tika
• Run acceptance tests

[davisagli]

Looks good, but I think we should increase the major version number and communicate this as a breaking change, since the new configuration will no longer work with older solr versions.

[reekitconcept]

Looks good, but I think we should increase the major version number and communicate this as a breaking change, since the new configuration will no longer work with older solr versions.

I'd like to argue against bumping the major version number.

Practical consideration: I want to provide fixes for both the 1.x and 2.x lines, which is standard practice for security incidents. This allows users to stay on their current major version. A patch release (or at most a minor bump) seems appropriate here.

Technical justification: We're not actually changing anything in the backend - we're simply providing an updated Docker image to address the vulnerability. There are two scenarios to consider:

a. Users on our vanilla image: No configuration changes required on their end. They just need to pull the new image. (They may need to update their stack configuration for the new Tika image, but that's it.)

b. Users with custom images: They'll need to rebuild their image, but that's their responsibility. In fact, they don't even need the new version of collective.solr - the fix lies entirely in their configuration update.

In summary: We're providing an updated Docker image with corresponding usage guidance, but nothing in our backend code is changing. In my view, this doesn't warrant a major version bump.

That said, we do need detailed release notes with clear instructions for both scenarios (a) and (b). I'll add these before finalizing the PR.

[davisagli]

@reekitconcept I don't feel strongly about whether we bump the major version number as long as we have clear directions in the release notes. We have to be clear that it is a breaking change in the Docker image (because unlike most patch upgrades, you have to update another part of your system in order for the update to work).

[reekitconcept]

@reekitconcept I don't feel strongly about whether we bump the major version number as long as we have clear directions in the release notes. We have to be clear that it is a breaking change in the Docker image (because unlike most patch upgrades, you have to update another part of your system in order for the update to work).

Ack, let's go for a pre-alpha version bump then. I'll add the instructions before removing the WIP.

[reekitconcept]

After reconsidering the versioning situation:

• v2: Since we're still in alpha, we can simply release a new alpha version.
• v1: There was never an official release, so there's nothing to patch. Essentially, v1 doesn't exist—we went straight to v2 with the new repo structure. (In hindsight, we probably shouldn't have called it v2; for all practical purposes, this is still the first version.) Users on the v1 alphas should migrate to v2, which they can do without any additional changes.