Description of problem:
The LUKS encryption format supports multiple key slots. This allows multiple distinct passphrases to be used to unlock the same master encryption key. It also allows for replacement of the passphrases, by adding a new one then removing the old one. This is supported in the 'cryptsetup' tool via several key management commands.
When QEMU is being used with a raw LUKS volume, admins can still use the cryptsetup tool to do key management, however, when LUKS is used in qcow2 this is not practical, because the LUKS header will not be in the place that cryptsetup is expecting.
There is thus a need to support key management in the qemu-img command. We need two commands
Needs to take an image file path, a key slot number, and the ID of a secret object providing the new passphrase.
Key slot could be made optional to let us pick a free slot
Needs to take an image file path, and either a key slot number, or the ID of a secret object providing the new passphrase.
If given a key slot, remove that exact slot
If given a passphrase, try to unlock each key slot until one succeeds, then remove that one.
We MUST NOT allow the last key slot to be removed, without explicit confirmation in some way. Perhaps --force option
It is unsafe to use qemu-img on an image used by a running guest, so we also likely need to have QMP + HMP commands which expose the exact same functionality as qemu-img for key slot mgmt.
QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks
Still working on coming to an agreement on the API/QMP syntax, most recent posting upstream:
Also see: http://etherpad.corp.redhat.com/luks-api for some recent thoughts
v2 posted upstream: https://lists.nongnu.org/archive/html/qemu-devel/2020-03/msg01838.html