janhoy opened a new pull request, #869:
URL: https://github.com/apache/solr-operator/pull/869
Makes Solr `9.11.0` the default, up from `9.10.0`.
## Operator work
None needed. I went through the 9.10 → 9.11 changes for everything the
operator depends on:
- JWT `blockUnknown` now defaults to `true` — the operator only ever writes
`solr.BasicAuthPlugin`, and writes `blockUnknown` explicitly, so nothing
changes.
- Basic Auth now rejects a password equal to its username — the operator's
bootstrapped credentials are randomly generated.
- `/{core}/replication` and `/update/extract` permission tightening — the
operator calls neither.
- New `solr.xml` `allowZkHosts` setting — optional cross-collection-join
hardening, already reachable through a custom `solr.xml` ConfigMap, so not
exposed as a CRD field here.
- `UPGRADECOREINDEX`, Luke shard aggregation, `LocalTikaExtractionBackend`
and gosu removal — no operator touchpoint.
One behaviour change earns an upgrade note: a Solr 9.11 node refuses to
start if its `major.minor` is below that of a node already running in the
cluster, so rolling a live cluster *back* to an older Solr no longer works.
## Security
9.11.0 carries the 9.10.1 fixes for three CVEs that all affect "Solr 9.10.0
and earlier":
- **CVE-2026-22022**, a RuleBasedAuthorizationPlugin predefined-permission
bypass. This one does reach operator-managed clusters, since the operator
bootstraps that plugin — but its generated `security.json` already contains the
documented mitigation (`{ "name": "all", "role":["admin"] }`), so operator
defaults were never exposed. Users supplying their own `security.json` may be.
- **CVE-2026-22444**, standalone-mode core creation — not reachable, the
operator only runs SolrCloud.
- **CVE-2025-66516**, XXE via XFA in PDFs — reachable for users who enable
the extraction module.
Both charts record the CVE fixes in their changelog.
`artifacthub.io/containsSecurityUpdates` is flipped to `"true"` on the Solr
chart only — the operator's own code carries no security fix, it just changes
which Solr version un-pinned clusters get.
## Compatibility matrix
Unchanged: `9.11` falls inside the existing `9.4`+ column and the `v0.10.x`
row already reads `YES`.
## Changelog
A `changed` entry in both `helm/solr/Chart.yaml` and
`helm/solr-operator/Chart.yaml`, plus a `security` entry in the Solr chart.
`helm/solr/values.yaml` ships `tag: ""`, so this bump moves every SolrCloud
that does not pin its own image tag onto Solr 9.11.0 at the next operator
upgrade — stated in both the changelog and the `v0.10.0` upgrade notes.
## Drive-by
`local-tutorial.adoc` installed `9.10.0` and then "upgraded" to `9.10.0`, so
its *Upgrade to newer version* section demonstrated nothing — both sites were
collapsed onto one version by the blanket sed in #807. The install step now
uses `9.10.0` and the upgrade step `9.11.0`.
## Testing
`make test`, `check-manifests`, `check-generated`, `check-helm` and
`check-docs` all pass.
`make e2e-tests` was **not** run — it fails before the suite starts, on
#859: `kind load` of the registry-pulled `solr:9.11.0` dies on Docker 29's
containerd image store with `ctr: content digest ...: not found`. Unrelated to
this change, and #860 is open against it. CI's e2e workflow is permanently
disabled, so it is evidence of nothing either way; this bump is worth a local
e2e run before merge, on a machine where #859 does not bite.
Produced with the `solr-version-support` skill proposed in #866, which
encodes the 15 duplicated version sites, the sizing rules above, the
compatibility matrix and the both-charts changelog requirement — none of which
any `make` target checks.
---
🤖 AI assisted
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
