Repository navigation
Validate that conditions.kibana.version is consistent with format_version #4052
Description
Summary
A package can declare a format_version that some of the Kibana versions in its conditions.kibana.version range cannot see. elastic-package check accepts this without a warning. The registry then hides the package from those stacks (Fleet sends spec.max with every search), so the declared Kibana range overstates where the package version is actually available.
Example
mimecast 3.6.0 (#20356) raised format_version from 3.3.2 to 3.6.0 to use the new deprecated: input field, but kept:
format_version: "3.6.0"
conditions:
kibana:
version: "^8.19.4 || ~9.0.7 || ^9.1.4"According to the format version guide, spec 3.6 is only supported from 9.4. Fleet's default REGISTRY_SPEC_MAX_VERSION (x-pack/platform/plugins/shared/fleet/common/constants/epm.ts) on each branch agrees:
| Kibana branch | Default spec max |
|---|---|
| 8.19 | 3.4 |
| 9.0 | 3.3 |
| 9.1 | 3.4 |
| 9.2, 9.3 | 3.5 |
| main (9.4) | 3.6 |
So on 8.19 through 9.3 the newest Mimecast offered is still 3.5.1, even though the 3.6.0 manifest and the published compatibility information say those stacks are supported.
Impact
- The Kibana constraint in the manifest, and in any docs or compatibility tables derived from it, does not match where the package can actually be installed.
- Users on those stacks quietly stop getting updates (including bug fixes) with no indication why. Maintainers may assume a fix has reached 8.19/9.x users when it hasn't.
- Authors may bump
format_versionto use a single new field without realising it cuts off older stacks.
Scope in elastic/integrations
On main, 21 of 497 packages have at least one Kibana range whose lower bound is a stack that cannot see the package's format_version. (This is a quick scan of each range's lower-bound minor against the table above, so treat it as approximate.)
| Package | format_version | conditions.kibana.version | Hidden from |
|---|---|---|---|
| azure_metrics | 3.4.0 | ~8.18.8 || ~8.19.5 || ~9.0.8 || ^9.1.5 |
9.0 |
| google_workspace | 3.4.0 | ^8.19.4 || ~9.0.7 || ^9.1.4 |
9.0 |
| panw_cortex_xdr | 3.4.0 | ^8.19.4 || ~9.0.7 || ^9.1.4 |
9.0 |
| qualys_was | 3.4.0 | ^8.18.0 || ^9.0.0 |
9.0 |
| zscaler_zia | 3.4.0 | ^8.18.0 || ^9.0.0 |
9.0 |
| sailpoint_identity_sc | 3.4.2 | ^8.19.2 || ^9.0.5 |
9.0 |
| neon_cyber | 3.5.0 | ^8.17.0 || ^9.0.0 |
9.0 |
| nginx_ingress_controller_otel | 3.5.0 | ^8.16.0 || ^9.0.0 |
9.0 |
| system_otel | 3.5.0 | ^8.18.0 || ^9.0.0 |
9.0 |
| microsoft_intune | 3.5.4 | ^8.18.0 || ^9.0.0 |
9.0 |
| doppel | 3.5.7 | ^8.19.14 || ^9.3.3 |
8.19 |
| contrast_security | 3.6.0 | ^8.19.0 || ^9.1.0 |
8.19, 9.1 (and 9.2, 9.3) |
| elastic_agent | 3.6.0 | ^8.15.0 || ^9.0.0 |
9.0 (and later < 9.4) |
| fleet_server | 3.6.0 | ^8.12.0 || ^9.0.0 |
9.0 (and later < 9.4) |
| mimecast | 3.6.0 | ^8.19.4 || ~9.0.7 || ^9.1.4 |
8.19, 9.0, 9.1 (and 9.2, 9.3) |
| veeam | 3.6.0 | ^8.19.0 || ^9.1.0 |
8.19, 9.1 (and 9.2, 9.3) |
| box_events | 3.6.1 | ^8.19.4 || ^9.1.4 |
8.19, 9.1 (and 9.2, 9.3) |
| okta | 3.6.1 | ^8.19.8 || ^9.2.2 |
8.19, 9.2 (and 9.3) |
| anduril_lattice | 3.6.3 | ^9.2.0 |
9.2, 9.3 |
| cisa_kevs | 3.6.6 | ^8.19.2 || ^9.0.5 |
8.19, 9.0 (and later < 9.4) |
| first_epss | 3.6.6 | ^8.19.2 || ^9.0.5 |
8.19, 9.0 (and later < 9.4) |
elastic_agent and fleet_server are bundled with Kibana and may be fine in practice; they are listed for completeness.
Proposal
Have elastic-package check (or package-spec validation) report an error, or at least a warning, when the lowest version in any conditions.kibana.version range is below the first stack that supports the declared format_version. The mapping already exists in the format version guide and could live next to it as data. The message should tell the author to either raise the Kibana constraint or lower format_version.
Open questions
- Should a stack that only supports the format through a
xpack.fleet.internal.registry.spec.maxoverride count as supported? I'd say no, since the default is what users get. - Does uploading a zip directly into Kibana enforce the same limit? That path skips the registry query and I haven't checked it.
Activity