On Fri, Feb 22, 2019 at 08:17:40PM +0100, Max Reitz wrote:
> On 19.02.19 13:50, Daniel P. Berrangé wrote:
> > If the qcow2 image does not have any encryption method specified in its
> > header, the user should not be providing any encryption options when
> > opening it. We already detect this if the user had set "encrypt.format"
> > but this field is optional so must consider any "encrypt.*" option to be
> > an error.
> >
> > Signed-off-by: Daniel P. Berrangé <berra...@redhat.com>
> > ---
> > block/qcow2.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/block/qcow2.c b/block/qcow2.c
> > index 65a54c9ac6..ecc577175f 100644
> > --- a/block/qcow2.c
> > +++ b/block/qcow2.c
> > @@ -1045,6 +1045,12 @@ static int
> > qcow2_update_options_prepare(BlockDriverState *bs,
> > ret = -EINVAL;
> > goto fail;
> > }
> > + if (encryptopts && qdict_size(encryptopts)) {
> > + error_setg(errp, "No encryption in image header, but
> > encryption "
> > + "options provided");
> > + ret = -EINVAL;
> > + goto fail;
> > + }
>
> Doesn't this make the block right before this one a bit superfluous?
Yes, in the sense that we'll still get an error if we removed the
prior block. The prior block has a more useful error message which
will help diagnosis though, so I thought it worth keeping both.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
