[Spice-devel] [spice-gtk] Fix TLS connections when both TLS/non-TLS port are given

[Marc-André Lureau]

On Wed, Mar 12, 2014 at 2:30 PM, Christophe Fergeau <cfergeau at redhat.com> wrote:
> On Wed, Mar 12, 2014 at 02:18:04PM +0100, Marc-André Lureau wrote:
>> On Wed, Mar 12, 2014 at 2:15 PM, Christophe Fergeau <cfergeau at redhat.com> wrote:
>> > On Tue, Mar 11, 2014 at 07:12:56PM +0100, Marc-André Lureau wrote:
>> >> On Tue, Mar 11, 2014 at 6:03 PM, Christophe Fergeau <cfergeau at redhat.com> wrote:
>> >> > When qemu only accepts TLS connections, but spice-gtk is given an URI with
>> >> > both port and tls-port specified, spice_session_channel_open_host() is
>> >> > first attempted to the non-TLS port, and when that fails,
>> >> > spice_channel_coroutine() retries a TLS connection.
>> >> >
>> >>
>> >> On a second thought, I think it was also a good idea to report an
>> >> error when the specified non-tls port is invalid.
>> >
>> > I did not get what you want here :-/ In which situation exactly do you want
>> > an error to be reported?
>>
>> When the given plain port doesn't exist or G_IO_ERROR_CONNECTION_REFUSED.
>>
>> That is, it is a good thing to report an error if the spice server
>> only accepts tls connection, but the client was given a plain port
>> too.
>>
>> No?
>
> You can probably hit this situation too when the server listens on both
> TLS/non-TLS ports and use 'tls-channel' to force some of the channels to
> use TLS.

If the server is listening on this port, it will not report an error here.

> Regardless of that, refusing to connect when the client got passed TLS and
> non-TLS port if the server is not listening on a non-TLS port is a change
> of behaviour with earlier versions. And I would not be surprised this
> change of behaviour would break some existing setups.

I am not convince this was desirable, so changing behaviour would be a
fix for me: reporting an error for an unexisting port is useful.

-- 
Marc-André Lureau