Research virtualization dependency freshness and update visibility

Observation

At commit df5909c, src/setup.rs::install_firecracker returns early when the managed Firecracker binary exists, and fetch_kernel returns early when the configured guest kernel file exists. src/update.rs updates coop and its coop-proxy companion, not Firecracker or the guest kernel. Lima and the host kernel have separate maintenance paths.

As a result, keeping coop current does not establish that its virtualization dependencies are current. The existing files may be recent or intentionally pinned; this finding does not establish that an installed component is vulnerable.

Research scope

• Inventory ownership and refresh behavior for coop, coop-proxy, Firecracker, jailer, guest kernels, guest images, Lima, and the host kernel.
• Determine which installed versions and artifact identities coop can reliably report, including custom binary and kernel paths.
• Propose a small diagnostic or status surface that distinguishes an observed version from an unknown or unavailable version and explains the relevant maintenance path.
• Assess how to compare managed components with upstream releases without treating every older version as vulnerable or overriding intentional pins.
• Separately scope an explicit infrastructure-update workflow: binary/jailer compatibility, artifact verification, running VMs, restart requirements, rollback, offline behavior, and custom paths.

Expected outcome

Produce a documented maintenance matrix and a recommendation for version reporting and update guidance. Separate low-impact reporting improvements from changes that replace infrastructure artifacts. Make clear that refreshing a guest kernel does not patch host KVM vulnerabilities. Validate any proposed reporting against managed, custom, missing, and offline installations on both backends.

Start by tracing src/setup.rs::install_firecracker and fetch_kernel, then inspect src/update.rs to map ownership and refresh behavior for the listed virtualization components. Done means a maintenance matrix and version-reporting recommendation covering managed, custom, missing, and offline installations on both backends, with infrastructure updates scoped separately.