On 2025-06-27 15:36:26 -0400 (-0400), Noah Meyerhans wrote: [...]
There are potential workarounds, but they're not necessarily trivial for users who are operating a cloud environment that they don't control. The primary workaround is to use a datadrive for VM metadata, rather than a network service, but that's a choice made by the cloud operator.
[...]I was read in on this back early in the year (in my capacity as an OpenStack vulnerability manager even though the vulnerability itself doesn't really affect typical OpenStack deployments), but sadly the LP bug seems to still be private which makes talking about specific mitigations for the vulnerability and workarounds for the new behavior difficult. Non-amd64 OpenStack environments are not common, though they do exist and I have access to some. This is primarily arm64 with maybe a smattering of aging ppc64 and s390x, and I've heard tell of riscv experiments in some organizations. That said, behavior changes in new versions of software necessitate that users ask the operators of their cloud services to make certain new configurations possible, I don't see this as being all that different if it were just coming in a new major Debian version.
The biggest risk I see with shipping it in stable is that an apt upgrade of cloud-init could leave some virtual machines in these environments unreachable after a reboot. It's very hard to estimate the actual impact due to the various factors involved, as well as overall lack of knowledge about the number and sizes of those environments. The OpenInfra Foundation does run surveys which include questions about some of this (architecture, deployment scale...) but it's elective self-reporting so at best only an indicator of proportion, assuming related biases don't skew responses to the point of complete uselessness in this case.
-- Jeremy Stanley
Attachment:
signature.asc
Description: PGP signature