[Spice-devel] [PATCH spice-gtk v2 2/4] uri: learn to parse spice+tls:// form

Marc-André Lureau marcandre.lureau at redhat.com
Tue Feb 20 21:56:40 UTC 2018


Hi

On Fri, Feb 16, 2018 at 11:30 AM, Daniel P. Berrangé
<berrange at redhat.com> wrote:
> On Fri, Feb 16, 2018 at 11:13:06AM +0100, marcandre.lureau at redhat.com wrote:
>> From: Marc-André Lureau <marcandre.lureau at redhat.com>
>>
>> spice:// has a weird scheme encoding, where it can accept both plain
>> and tls ports with URI query parameters. However, it's not very
>> convenient nor very common to use (who really want to mix plain & tls
>> channels?).
>
> Is it worth formally deprecating the mixing of plain & tls on a per
> channel basis in QEMU ?  The idea that you can be secure, and yet
> still have some channels plain text is really dubious and promotes
> dangerous practice to users.
>

It may be possible to have channels that are secured above the spice
channels (with the so called "port" channel), so you may want to have
a mix of plain and tls prots. In practice, I don't think anyone does
that.

As you said, it is best to enforce the behaviour on the server side, in qemu.

On the client side, we could default to --spice-secure-channels=all
and have some extra warnings.

In any case, that URI series doesn't need to be delayed for it I imagine.


>>
>> Instead, let's introduce the more readable form spice+tls://host:port
>> This form will not accept 'port' or 'tls-port' query string parameter.
>>
>> Signed-off-by: Marc-André Lureau <marcandre.lureau at redhat.com>
>
> 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 :|


More information about the Spice-devel mailing list