[libvirt] [PATCH v2 0/5] qemu: Forbid old qcow/qcow2 encryption

[Peter Krempa]

On Thu, May 31, 2018 at 07:22:28 -0400, John Ferlan wrote:
> 
> 
> On 05/31/2018 02:18 AM, Peter Krempa wrote:
> > On Wed, May 30, 2018 at 16:14:31 -0400, John Ferlan wrote:
> >>
> >>
> >> On 05/23/2018 10:13 AM, Peter Krempa wrote:
> >>> The old qcow/qcow2 encryption format is so broken that qemu decided to
> >>> drop it completely. This series forbids the use of such images even with
> >>> qemus prior to this and removes all the cruft necessary to support it.
> >>>
> >>> v2:
> >>>  - fixed check to include the qcow format too
> >>>  - reworded the error message slightly
> >>>  - split second patch into two with proper justification for the
> >>>    user-alias test since checking LUKS there actually makes sense
> >>>
> >>> Peter Krempa (5):
> >>>   tests: qemuxml2argv: Drop disk encryption from 'interface-server' test
> >>>   tests: qemuxml2argv: Verify that disk secret alias is correct with
> >>>     user-aliases
> >>>   tests: qemublock: Switch to qcow2+luks in test files
> >>>   qemu: domain: Forbid storage with old QCOW2 encryption
> >>>   qemu: Remove code for setting up disk passphrases
> >>>
> >>
> >> Why not remove it from storage as well? It's not like anything could or
> >> would want to use whatever the storage driver created. There's always
> >> the fall back to indicate to use qemu-img for the die hards.
> > 
> > If we've ever supported the use case of converting a qcow2 encrypted
> > volume even into a unencrypted volume, we should keep that for allowing
> > migration from those volumes.
> > 
> 
> Without (at least parts of) for qemu's 2.9 or later:
> 
> https://www.redhat.com/archives/libvir-list/2018-May/msg01268.html
> 
> it won't work anyway because of qemu secret work.

Well, given that the required setup for qcow2 encryption is almost
identical to luks I think we can support the old encryption on the input
of the conversion process.

> I think you probably need to make some documentation updates too. If not
> removing things, then updating certain pages to indicate as of libvirt
> 4.X.0 it won't be possible to use for domains (and possibly storage).

Hmm, yeah, there should be a section describing the <encryption>
element. I'll add a note there and into news.xml. (probably as a
separate patch.

> 
> John
> 
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180531/0bec1e44/attachment-0001.sig>