Running with osx client 0.16.0 r10828 against a fedora 21 0.16.0 r10854 server, when I start a session with ...
XPRA_CRYPTO_INITIAL_PADDING="PKCS#7" XPRA_ENCRYPT_FIRST_PACKET="1" dbus-launch xpra start :13 --no-daemon --bind-tcp=0.0.0.0:2200 --start-new-commands=yes --start-child=xterm --start-child=xterm --html=on --sharing --password-file=password --encryption-keyfile=key --encryption=AES
... and I'm then foolish enough to try to pull any xpra info, I have no luck ...
[tlaloc@jimador ~]$ xpra info :13 --password-file=password --encryption-keyfile=key --encryption=AES receiving data using AES encryption disconnect: unencrypted packet dropped
... and the server's output...
2015-10-15 16:50:20,148 New unix-domain connection received on /home/tlaloc/.xpra/jimador.spikes.eng-13 2015-10-15 16:50:20,150 receiving data using AES encryption 2015-10-15 16:50:20,197 New unix-domain connection received on /home/tlaloc/.xpra/jimador.spikes.eng-13 2015-10-15 16:50:20,198 receiving data using AES encryption 2015-10-15 16:50:20,262 Connection lost 2015-10-15 16:50:20,262 Disconnecting client '/home/tlaloc/.xpra/jimador.spikes.eng-13': 2015-10-15 16:50:20,262 unencrypted packet dropped 2015-10-15 16:50:20,263 Connection lost
[tlaloc@jimador ~]$ dbus-launch xpra start :13 --no-daemon --bind-tcp=0.0.0.0:2200 --start-new-commands=yes --start-child=xterm --start-child=xterm --password-file=password --encryption-keyfile=key --encryption=AES
... all works as hoped.
Edited bug title: this has nothing to do with PKCS#7
or xpra info
: you get the same results with "xpra attach" (or any other client subcommand), and with different a padding scheme.
And this is really not a bug: the point of XPRA_ENCRYPT_FIRST_PACKET
being disabled by default is that it is a backwards incompatible change.
This works:
XPRA_CRYPTO_INITIAL_PADDING="PKCS#7" XPRA_ENCRYPT_FIRST_PACKET="1" \ xpra start :13 \ --auth=file --password-file=password.txt \ --encryption=AES --encryption-keyfile=aes.txt
XPRA_CRYPTO_INITIAL_PADDING="PKCS#7" XPRA_ENCRYPT_FIRST_PACKET="1" \ xpra info :13 \ --auth=file --password-file=password.txt \ --encryption=AES --encryption-keyfile=aes.txt
Please also note how the commands above do not include arguments that are not relevant to this bug: daemon, bind-tcp, start-new-commands, multiple start-child, html, sharing.
@afarr: please close unless I am missing something.
Ahh... didn't think of the use of the environment variables, for some reason (and I'll take more care to pare out the probably irrelevant command details).
I don't see anything you missed either. Closing.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1006