Re: iotest 233 failing

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Jun 10, 2021 at 03:34:46PM -0500, Eric Blake wrote:
> I'm now getting failures on iotest 233:
> 
> 233   fail       [15:26:01] [15:26:03]   2.1s   (last: 1.3s)  output mismatch (see 233.out.bad)
> --- /home/eblake/qemu/tests/qemu-iotests/233.out
> +++ 233.out.bad
> @@ -65,6 +65,6 @@
>  == final server log ==
>  qemu-nbd: option negotiation failed: Verify failed: No certificate was found.
>  qemu-nbd: option negotiation failed: Verify failed: No certificate was found.
> -qemu-nbd: option negotiation failed: TLS x509 authz check for CN=localhost,O=Cthulhu Dark Lord Enterprises client1,L=R'lyeh,C=South Pacific is denied
> -qemu-nbd: option negotiation failed: TLS x509 authz check for CN=localhost,O=Cthulhu Dark Lord Enterprises client3,L=R'lyeh,C=South Pacific is denied
> +qemu-nbd: option negotiation failed: TLS x509 authz check for C=South Pacific,L=R'lyeh,O=Cthulhu Dark Lord Enterprises client1,CN=localhost is denied
> +qemu-nbd: option negotiation failed: TLS x509 authz check for C=South Pacific,L=R'lyeh,O=Cthulhu Dark Lord Enterprises client3,CN=localhost is denied
>  *** done
> Failures: 233
> Failed 1 of 1 iotests
> 
> Looks like I recently updated to gnutls-3.7.2-1.fc34 on June 1, could
> that be the culprit for the error message being reordered?

It is possible I guess. They have indeed made such a change in the past
and reverted it when I pointed out that this is effectively an ABI for
apps, because access control lists are based on matching the distinguish
name string, as an opaque string. The cause certainly needs investigating
as a matter of urgency because this is ABI for QEMU's authz access control
lists.


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 :|