| Message ID | 20180509165530.29561-6-mreitz@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 05/09/2018 11:55 AM, Max Reitz wrote: > Currently, you can give no encryption format for a qcow file while still > passing a key-secret. That does not conform to the schema, so this > patch changes the schema to allow it. > > Signed-off-by: Max Reitz <mreitz@redhat.com> > --- > ## > # @BlockdevQcowEncryptionFormat: > # > # @aes: AES-CBC with plain64 initialization vectors > # > +# @from-image: Determine the encryption format from the image > +# header. This only allows the use of the > +# key-secret option. (Since: 2.13) > +# > # Since: 2.10 > ## > { 'enum': 'BlockdevQcowEncryptionFormat', > - 'data': [ 'aes' ] } > + 'data': [ 'aes', 'from-image' ] } Overkill. Why not just: > > ## > # @BlockdevQcowEncryption: > @@ -2728,9 +2748,11 @@ > # Since: 2.10 > ## > { 'union': 'BlockdevQcowEncryption', > - 'base': { 'format': 'BlockdevQcowEncryptionFormat' }, > + 'base': { '*format': 'BlockdevQcowEncryptionFormat' }, > 'discriminator': 'format', > - 'data': { 'aes': 'QCryptoBlockOptionsQCow' } } > + 'default-variant': 'from-image', 'default-variant': 'aes' > + 'data': { 'aes': 'QCryptoBlockOptionsQCow', and call it good, because there are no other options to pick from, so 'from-image' would always resolve to 'aes' anyway.
On Thu, May 10, 2018 at 09:24:24AM -0500, Eric Blake wrote: > On 05/09/2018 11:55 AM, Max Reitz wrote: > > Currently, you can give no encryption format for a qcow file while still > > passing a key-secret. That does not conform to the schema, so this > > patch changes the schema to allow it. > > > > Signed-off-by: Max Reitz <mreitz@redhat.com> > > --- > > > ## > > # @BlockdevQcowEncryptionFormat: > > # > > # @aes: AES-CBC with plain64 initialization vectors > > # > > +# @from-image: Determine the encryption format from the image > > +# header. This only allows the use of the > > +# key-secret option. (Since: 2.13) > > +# > > # Since: 2.10 > > ## > > { 'enum': 'BlockdevQcowEncryptionFormat', > > - 'data': [ 'aes' ] } > > + 'data': [ 'aes', 'from-image' ] } > > Overkill. Why not just: > > > ## > > # @BlockdevQcowEncryption: > > @@ -2728,9 +2748,11 @@ > > # Since: 2.10 > > ## > > { 'union': 'BlockdevQcowEncryption', > > - 'base': { 'format': 'BlockdevQcowEncryptionFormat' }, > > + 'base': { '*format': 'BlockdevQcowEncryptionFormat' }, > > 'discriminator': 'format', > > - 'data': { 'aes': 'QCryptoBlockOptionsQCow' } } > > + 'default-variant': 'from-image', > > 'default-variant': 'aes' > > > + 'data': { 'aes': 'QCryptoBlockOptionsQCow', > > and call it good, because there are no other options to pick from, so > 'from-image' would always resolve to 'aes' anyway. Sounds reasonable because qcowv1 is a dead format we don't intend to add more features to. Regards, Daniel
On 2018-05-10 16:24, Eric Blake wrote: > On 05/09/2018 11:55 AM, Max Reitz wrote: >> Currently, you can give no encryption format for a qcow file while still >> passing a key-secret. That does not conform to the schema, so this >> patch changes the schema to allow it. >> >> Signed-off-by: Max Reitz <mreitz@redhat.com> >> --- > >> ## >> # @BlockdevQcowEncryptionFormat: >> # >> # @aes: AES-CBC with plain64 initialization vectors >> # >> +# @from-image: Determine the encryption format from the image >> +# header. This only allows the use of the >> +# key-secret option. (Since: 2.13) >> +# >> # Since: 2.10 >> ## >> { 'enum': 'BlockdevQcowEncryptionFormat', >> - 'data': [ 'aes' ] } >> + 'data': [ 'aes', 'from-image' ] } > > Overkill. Why not just: > >> ## >> # @BlockdevQcowEncryption: >> @@ -2728,9 +2748,11 @@ >> # Since: 2.10 >> ## >> { 'union': 'BlockdevQcowEncryption', >> - 'base': { 'format': 'BlockdevQcowEncryptionFormat' }, >> + 'base': { '*format': 'BlockdevQcowEncryptionFormat' }, >> 'discriminator': 'format', >> - 'data': { 'aes': 'QCryptoBlockOptionsQCow' } } >> + 'default-variant': 'from-image', > > 'default-variant': 'aes' > >> + 'data': { 'aes': 'QCryptoBlockOptionsQCow', > > and call it good, because there are no other options to pick from, so > 'from-image' would always resolve to 'aes' anyway. Hmmmm. Yes. :-) Max
diff --git a/qapi/block-core.json b/qapi/block-core.json index 092a1aba2d..d98af0a71d 100644 --- a/qapi/block-core.json +++ b/qapi/block-core.json @@ -2712,15 +2712,35 @@ 'data': { 'flags': 'Qcow2OverlapCheckFlags', 'mode': 'Qcow2OverlapCheckMode' } } +## +# @BlockdevQcowEncryptionSecret: +# +# Allows specifying a key-secret without specifying the exact +# encryption format, which is determined automatically from the image +# header. +# +# @key-secret: The ID of a QCryptoSecret object providing the +# decryption key. Mandatory except when probing +# image for metadata only. +# +# Since: 2.13 +## +{ 'struct': 'BlockdevQcowEncryptionSecret', + 'data': { '*key-secret': 'str' } } + ## # @BlockdevQcowEncryptionFormat: # # @aes: AES-CBC with plain64 initialization vectors # +# @from-image: Determine the encryption format from the image +# header. This only allows the use of the +# key-secret option. (Since: 2.13) +# # Since: 2.10 ## { 'enum': 'BlockdevQcowEncryptionFormat', - 'data': [ 'aes' ] } + 'data': [ 'aes', 'from-image' ] } ## # @BlockdevQcowEncryption: @@ -2728,9 +2748,11 @@ # Since: 2.10 ## { 'union': 'BlockdevQcowEncryption', - 'base': { 'format': 'BlockdevQcowEncryptionFormat' }, + 'base': { '*format': 'BlockdevQcowEncryptionFormat' }, 'discriminator': 'format', - 'data': { 'aes': 'QCryptoBlockOptionsQCow' } } + 'default-variant': 'from-image', + 'data': { 'aes': 'QCryptoBlockOptionsQCow', + 'from-image': 'BlockdevQcowEncryptionSecret' } } ## # @BlockdevOptionsQcow:
Currently, you can give no encryption format for a qcow file while still passing a key-secret. That does not conform to the schema, so this patch changes the schema to allow it. Signed-off-by: Max Reitz <mreitz@redhat.com> --- qapi/block-core.json | 28 +++++++++++++++++++++++++--- 1 file changed, 25 insertions(+), 3 deletions(-)