SPICE transport issues

[a-sh1]

Hi,

I've faced some issues while testing openuds server, please take a look.

1. when trying to connect to oVirt linked clone service using spice direct transport, error is displayed onscreen and in udsclient.log:
   ERROR 2020-07-06 12:16:44,278 got error: u'as_file_ns'

Workaround is to change server/src/uds/transports/SPICE/spice.py, line 109 from:
return self.getScript('scripts/{}/tunnel.py', osName, sp)
to
return self.getScript('scripts/{}/direct.py', osName, sp)

2. CA certificate from ovirt-engine is written to temporary .uds file ca parameter as:
   ca=-----BEGIN CERTIFICATE-----\\n....certificatedata....\\n-----END CERTIFICATE-----
   Newline symbols here are \\n instead of \n which makes certificate invalid and virt-viewer can't connect to virtual machine.
   I've used Windows 8.1 client machine for this test.

Workaround is to change server/uds/transports/SPICE/remote_viewer_file.py, line 105 from:
ca = self.ca.strip().replace('\n', '\\\\n')
to
ca = self.ca.strip().replace('\n', '\\n')

Also I've mentioned that in uds 2.2 server log CA part looks like:

theFile = '''[virt-viewer]
...
ca=-----BEGIN CERTIFICATE-----\\n...certificatedata...\\n-----END CERTIFICATE-----
...

and in 3.0 log like:
{'as_file': '[virt-viewer]...\nca=-----BEGIN CERTIFICATE-----\\\\n...certificatedata...\\\\n-----END CERTIFICATE-----...}

So it is possibly why \\n is written to .uds file instead of \n.

[dkmstr]

Thanks for your detailed report.

Point 1 is not only the workaround, it's also the solution :). The problem is that on the upgrade process to 3.0 security model (separated data from script, and signed scripts), probably there was some confussion in there, and it was using the incorrect template script.

Point 2 is also the solution. On 2.x there was an string insertion, so the \\n passed to \n (i mean, that the \n on destination was a "code string" "\\n", that once interpreted will become "\n"), but now on 3.0 onwards, this is provided as data, so it needs to be \n. (no conversion is needed here, because the value will not be interpreted by an script, just used)

Thanks for both solutions, if you can check it now, i'll appreciate it ;-)

[a-sh1]

Hi,
I've already tested this fixes, spice direct transport works fine. I was hoping you can add them to the code :)

[dkmstr]

sorry, i didn't explain correctly.
The fixes you proposed are already added to the base code (done it when you reported it ;-) ), and i was wondering if you can test the fixes in the code, (that must match yours). :)

[a-sh1]

Did the test with fixes in the code - the problem is solved. Thanks! :)