Comment 86 for bug 1996188

@Jeremy: we may need to hold off a day or so for the announcement.

In working on how this can be backported to stable/train, I realized that the cinder patches for zed through wallaby are not ready yet. Here's what's up.

Beginning with oslo.utils 3.14.0 (current release is 6.1.0), the imageutils.QemuImgInfo class supports a 'format' parameter in the initializer that takes 'json' as a value (default is 'human'). It is the responsibility of the consumer to get the data from 'qumu-img info' with the '--output=json' flag, and pass this data to the initializer. (This was introduced by change Iefa139dc4bcea864cb.)

The 'format-specific' attribute of the QemuImgInfo class, which we need to check the VMDK subtype, is supported beginning with oslo.utils 4.1.0 by change I133da07a5a9628b8a9.

BUT ... cinder doesn't request json format from 'qemu-img info' until change Ia0353204abf8494671, which is only in current master ... and if you use the default 'human' format, QemuImgInfo.format_specific is *always* None [0].

So the current cinder patches for zed->wallaby won't let a bad VMDK sneak through, but will raise ImageUnacceptable on *all* VMDKs. (This is tested by test_check_vmdk_image_handles_missing_info in the TestVmdkImageChecks class in the patches.)

So the current patches for zed->wallaby block the security risk, but will cause a bad regression for anyone who actually uses VMDKs.

I think the cinder team needs to backport change Ia0353204abf8494671 as far as it will go on an expedited basis before we release these patches. Or I could simply roll the change into these patches, though strictly speaking, it's unrelated.

I'll email the cinder coresec team separately to get a quick response on what the acceptable strategy is.

[0] https://opendev.org/openstack/oslo.utils/src/commit/d49d5944824f15d00e04e1b9c7f8c3b03b440c95/oslo_utils/imageutils.py#L86