for what it worth i think the image inspector work in oslo effectivly mitigates much of the securtiy concern of invoking qemu-image or other tools to do things like resize/format conversion as we have effecctivly promoted the image form untrusted to trusted.
Agree. Even with it, I'd certainly be happy with a more-secure qemu-img alternative for our usage (or, really, I'd just prefer qemu-img took this more seriously).
now its also true that unless we reject images with featuer we do not have knowldage of
To be clear, we do that today: https://github.com/openstack/oslo.utils/blob/master/oslo_utils/imageutils/fo... Any feature we don't have mapped makes us reject the image. This was the direct recommendation from the qemu team.
there is a bit of an arms race between preventing a unsafe feature from being used and updating it but we can ligitiamtly do that
For an inspector, it's easy to default to "fail on unknown features". If a new one pops up, we can evaluate and bless/ban it and move on. For a reimplementation of qemu-img, it's truly an arms race to keep up with not just identifying but _implementing_ all those features.
yep that a very nice capablity and sideefect of the way the image inspector is stream based. for some format we unfortuently do need to process the stream of the entire disk to determin if its safe but for many formats we only need the first few bytes and we can bail early if we ever detect its invailed without processign the rest.
We have no formats that we need to process the entire stream (currently). Even LUKS is stream-inspectable with decryption to inspect the first block of the encapsulated disk. For glance, the upload process can _never_ store the image to inspect it first (there's literally no place to do it). --Dan