Following the recent problems with lz4 (in particular Raising Lazarus - The 20 Year Old Bug that Went to Mars: Linux Kernel, ffmpeg..). There have been numerous vulnerabilities in ffmpeg over the years, and even the venerable zlib is not immune to bugs. And zlib is also used in PNG...
It makes sense to assume that every non-trivial input parser is going to have issues.
This is more problematic for platforms like win32 and osx, for which we are forced to ship a large number of libraries ourselves because their respective OS vendor provides very little: this means we also become responsible for updating the installers every time a new flaw is discovered. It also means that the more security conscious users cannot pre-emptively disable this code.
The solution is to provide options to allow as many of those parsers to be switched on or off via the command line (or configuration file) - which is much easier and faster than installing newer versions of the software.
The priority should be for the parsers that can most easily be abused: the network layer must parse data before the connection is authenticated.
List of new switches required:
zlib(at least one should be enabled)
rencode(at least one must be enabled)
yamlpacket encoding support
compressors" and "
packet-encoders" are enabled
Dealing with errors much improved in r6969.
lz4with all compression levels, not just with
1as per previous versions)
bz2, which is now replaced by
lzo(so don't mix, client and servers using those versions)
This is as much for your own information as it is for testing:
xpra start :10 --compressors=lz4,lzo xpra attach :10 --compressors=zlib
the client should fail with (the same message should appear in the server log file and include the client's connecting TCP address or socket):
Failed to connect: 'disconnect: invalid compression: zlib is not enabled'
xpra infoor session-info's "Connection" tab
lz4should be used
--compressors=none' forces the client to not use compression (either
-z=0or also using '
yaml- your build must have them all to test)
--encoding=which is not in the list of available encodings
(raising: blocker for release)
--compressors=lz4,lzoand a client with
packet no 0 data: 'disconnect: invalid compression: zlib is not enabled\n' - small typo
lz4is used by the client with
---compressors=allon both the client and the server.
--compressors=nonecauses the client to fail to connect unless the client selects
--compressors=noneas an argument. I get the same
packet no 0 data: 'disconnect: invalid compression: zlib is not enabled\n' if I don't force the client to use
--encodings=png,webpand the client with
--encodings=h264will allow the client to connect anyway, but with
h264,jpeg,png,rgb,rgb32encodings listed for the client in
Session Info, and the server has
png,webp. I'm pretty sure that's not expected behavior.
xpra.confon the client to only
rgb24connects anyway as well, with the same encodings listed, with rgb24 as well so the list becomes
pngand the client
rgb24allows the client to connect anyway with
jpeg,png,rgb,rgb24showing up in
It currently looks like the Win-Client is partially ignoring what encodings it is allowed to use.
I assume you mean the "
\n"? The plain-text response detection should be fixed in r7078 so the output now shows up as:
Failed to connect: 'disconnect: invalid packet encoding: yaml is disabled'
(..) I'm pretty sure that's not expected behavior.
Right you are, this is fixed in r7081.
Changing the xpra.conf..
Probably the same bugs fixed above.
I've also improved the error messages that come out.
Can you try again please?
--encodings=png,webpand the client tries to connect with
--encodings=rgb24), the Windows client disconnects with the following message:
2014-08-01 16:00:45,634 server failure: disconnected before the session could be established 2014-08-01 16:00:45,635 server requested disconnect: server error accepting new connection 2014-08-01 16:00:45,888 Connection lost
with the same print on the server side. Is this expected behavior?
Other than that it seems to be behaving nicely.
server failure: disconnected before the session could be established
That's what older servers say (you were on r7041), newer ones provide more informative messages.
Note: this was not tested fully for packet encoders, see ticket:473#comment:22
And doubly so:
And one more: r7689.
As per https://winswitch.org/trac/ticket/266, we have a problem where older versions of xpra (before v0.11.x it seems) do not send zlib=1 and so we end up not using compression at all (or worse before r7689: crashing the connection!). That is fixed in r7691. (this change is for v0.14.x only as trunk is not compatible with versions older than 0.12 anyway)
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/614