xpra icon
Bug tracker and wiki

Opened 5 years ago

Closed 5 years ago

#1158 closed defect (fixed)

0.16.3 r12204 osx client giving "ValueError: unsupported hash type md5" error

Reported by: alas Owned by: alas
Priority: blocker Milestone: 0.17
Component: client Version: trunk
Keywords: Cc:

Description

Trying to connect a 0.16.3 r12204 osx client (your /dists repo) to a 0.16.4 r11617 fedora 23 server (my build) with encryption & password is throwing a number of apparent encryption errors.

Launched the server with xpra start --start-new-commands=yes --sharing --password-file=a-file --encryption-keyfile=another-file --encryption=AES.

Connected with a 0.16.4 r12312 windows client (your /beta repo) with xpra attach tcp --sharing --password-file=a-file --encryption-keyfile=another-file --encryption=AES successfully.

Then, in order to finally close ticket 489 ... tried the osx 0.16.3 r12204 client from your /dists directory with ./xpra attach tcp --sharing --password-file=a-file --encryption-keyfile=another-file --encryption=AES

The osx client was unhappy:

2016-04-07 18:30:31,871 code for hash md5 was not found.
Traceback (most recent call last):
  File "hashlib.pyc", line 147, in <module>
  File "hashlib.pyc", line 97, in __get_builtin_constructor
    This Python implementations based on the hmac module about as fast
ValueError: unsupported hash type md5
2016-04-07 18:30:31,873 code for hash sha1 was not found.
Traceback (most recent call last):
  File "hashlib.pyc", line 147, in <module>
  File "hashlib.pyc", line 97, in __get_builtin_constructor
    This Python implementations based on the hmac module about as fast
ValueError: unsupported hash type sha1
xpra initialization error:
 cannot use encryption: no ciphers available (pycrypto must be installed)

Change History (3)

comment:1 Changed 5 years ago by Antoine Martin

Priority: majorblocker
Status: newassigned

comment:2 Changed 5 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Status: assignednew

This was caused by #876: we now build our own openssl library and ship it (r11865).
Later, in r12013, the python version was updated, which caused python to be rebuilt against the new libraries rather than the system ones.
But the 0.16.x branch did not ship the new libraries, causing the failure at runtime.

This should be fixed in r12370. I have pulled the broken 0.16.3 builds from the repository.
I have uploaded a 0.16.4 beta build with this change. Please close if this works for you.

comment:3 Changed 5 years ago by alas

Resolution: fixed
Status: newclosed

Looks like it was just client side indeed.

0.16.4 r12370 osx client against a 0.16.4 r11617 fedora 23 server works as expected/hoped.

(I would note that the osx-app worked as expected, but when I tried to install the osx-pkg it seemed to, even after manually approving through the Security Preferences, not actually install... though it also gave no warnings. I suspect I've seen this before in the case of other versions being installed elsewhere causing the .pkg to fail to install and also fail to give any indication of said failure... I'll see about confirming that's what I'm seeing before making a ticket.)

This issue looks sorted. Closing.

Note: See TracTickets for help on using tickets.