Xpra: Ticket #614: make it possible to enable and disable all input parsers individually (lz4, codecs, etc)

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:

Sun, 27 Jul 2014 05:03:14 GMT - Antoine Martin:

Sun, 27 Jul 2014 11:11:42 GMT - Antoine Martin:

Remaining tasks:

Sun, 27 Jul 2014 15:23:58 GMT - Antoine Martin:

Dealing with errors much improved in r6969.

Mon, 28 Jul 2014 05:44:18 GMT - Antoine Martin: owner changed


This is as much for your own information as it is for testing:

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'

Tue, 29 Jul 2014 10:56:15 GMT - Antoine Martin: priority changed

(raising: blocker for release)

Thu, 31 Jul 2014 21:37:05 GMT - J. Max Mena:

Testing Win7 r7041 against Fedora 20 r7041 server:

packet no 0 data: 'disconnect: invalid compression: zlib is not enabled\n' - small typo

packet no 0 data: 'disconnect: invalid compression: zlib is not enabled\n' if I don't force the client to use --compressors=none.

It currently looks like the Win-Client is partially ignoring what encodings it is allowed to use.

Fri, 01 Aug 2014 11:18:44 GMT - Antoine Martin: owner changed

"small typo"

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?

Fri, 01 Aug 2014 23:06:54 GMT - J. Max Mena:

Retested with newer Windows r7088 against Fedora 20 r7041(our current builds don't have x264 for some odd reason):

with the same print on the server side. Is this expected behavior?

Other than that it seems to be behaving nicely.

Sat, 02 Aug 2014 04:11:10 GMT - Antoine Martin: status changed; resolution set

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.


Wed, 20 Aug 2014 13:22:48 GMT - Antoine Martin:

Note: this was not tested fully for packet encoders, see ticket:473#comment:22

And doubly so:

Thu, 18 Sep 2014 15:29:44 GMT - Antoine Martin:

And one more: r7689.

Thu, 18 Sep 2014 15:51:58 GMT - Antoine Martin:

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)

Sat, 23 Jan 2021 05:00:55 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/614