On Mon, Jul 19, 2021 at 08:12:58PM -0500, Eric Blake wrote:
> On Mon, Jul 19, 2021 at 10:06:01AM +0200, Thomas Huth wrote:
> > Hi,
> >
> > iotest 206 fails for me with:
> >
>
> > --- 206.out
> > +++ 206.out.bad
> > @@ -99,55 +99,19 @@
> >
> > {"execute": "blockdev-create", "arguments": {"job-id": "job0", "options":
> > {"driver": "qcow2", "encrypt": {"cipher-alg": "twofish-128", "cipher-mode":
> > "ctr", "format": "luks", "hash-alg": "sha1", "iter-time": 10, "ivgen-alg":
> > "plain64", "ivgen-hash-alg": "md5", "key-secret": "keysec0"}, "file":
> > {"driver": "file", "filename": "TEST_DIR/PID-t.qcow2"}, "size": 33554432}}}
> > {"return": {}}
> > +Job failed: Unsupported cipher algorithm twofish-128 with ctr mode
> > {"execute": "job-dismiss", "arguments": {"id": "job0"}}
> > {"return": {}}
>
> >
> > Looks like it is missing a check for the availability of the corresponding
> > crypto stuff? Does anybody got a clue how to fix this?
>
> What system is this on? Which crypto library versions are installed?
> I suspect this is related to Dan's effort to speed up crypto by
> favoring gnutls over nettle, where the switch in favored libraries
> failed to account for whether twofish-128 is supported?
>
> https://lists.gnu.org/archive/html/qemu-devel/2021-07/msg03886.html
Yes, the gnutls provider doesn't support twofish. This doesn't matter
in real world usage because no one is seriously going to ask for twofish
instead of AES for luks encryption.
I guess that test suite was simply trying to ask for some non-default
values though.
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 :|
