OpenSSL on Debian #47
Labels
No Label
bug
build
dependencies
developers
documentation
duplicate
enhancement
formatting
invalid
legal
mobile
obsolete
packaging
performance
protocol
question
refactoring
regression
security
test
translation
usability
wontfix
No Milestone
No project
No Assignees
1 Participants
No due date set.
Dependencies
No dependencies set.
Reference: Bitmessage/PyBitmessage-2024-12-19#47
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Debian 6.0.6
Kernel 3.7.8
Python 2.6.6
PyOpenSSL and OpenSSL installed.
python bitmessagemain.py
Traceback (most recent call last):
File "bitmessagemain.py", line 55, in
import highlevelcrypto
File "/home/rricci/Build/sources/PyBitmessage/highlevelcrypto.py", line 1, in
import pyelliptic
File "/home/rricci/Build/sources/PyBitmessage/pyelliptic/init.py", line 16, in
from .openssl import OpenSSL
File "/home/rricci/Build/sources/PyBitmessage/pyelliptic/openssl.py", line 427, in
raise Exception("Couldn't load the OpenSSL library. You must install it. Error message:"+err)
TypeError: cannot concatenate 'str' and 'exceptions.AttributeError' objects
This looks like the exception is actually happening where openssl.py is trying to build the error message to print out. It's trying to concatenate the literal string with "err", which is some kind of object. I'm not in a position to check this out right now, but I wonder what would happen if you rewrote line 426 like this:
I doubt that there is any interesting information in err that is worth printing anyway; it is likely just something like "Error: could not find 'SSL' library". I can just take the 'err' printing out of the code although ultimately the reason rricci2009 is seeing this error is because it cannot find OpenSSL for some reason.
I have not tested this on Debian.
I have changed the code to get rid of the 'exceptions.AttributeError' and changed the code to again try executing the problematic statements outside of any exception handler so that we can read whatever information the exceptions spit out in case it is of any value.
rricci2009, this won't fix your problem but it will spit out information that may help diagnose it.
Some changes:
OpenSSL = _OpenSSL(find_library('ssl'))
File "/home/rricci/Build/sources/PyBitmessage/pyelliptic/openssl.py", line 292, in init
self.PKCS5_PBKDF2_HMAC = self._lib.PKCS5_PBKDF2_HMAC
File "/usr/lib/python2.6/ctypes/init.py", line 366, in getattr
func = self.getitem(name)
File "/usr/lib/python2.6/ctypes/init.py", line 371, in getitem
func = self._FuncPtr((name_or_ordinal, self))
AttributeError: /usr/lib/i686/cmov/libssl.so.0.9.8: undefined symbol: PKCS5_PBKDF2_HMAC
Any idea?
I have modified the source with:
pybitmessagemain.py
pyelliptic/openssl.py:
Can you check it?
Another bug?
<main.singleListener object at 0x973b16c> connected to 59.167.95.209 during INCOMING request.
remoteCommand version from 59.167.95.209
Remote node useragent: /PyBitmessage:0.2.4/ stream number: 1
The streamNumber of this sendDataThread (ID: 164422188 ) at setup() is -1
setting the stream number in the sendData thread (ID: 164422188 ) to 1
Sending verack
Sending version message
remoteCommand verack from 59.167.95.209
verack received
Connection fully established with 59.167.95.209 8444
broadcasting addr from within connectionFullyEstablished function.
Broadcasting addr with 1 entries.
addrsInMyStream.items() [('188.117.4.216', (8444, 1361235624)), ('50.116.37.18', (8444, 1361237442)), ('84.10.200.166', (8444, 1361224192)), ('86.152.76.245', (8444, 1361236434)), ('68.49.217.2', (8444, 1361231182)), ('93.182.129.84', (8444, 1361227357)), ('1.4.239.172', (8444, 1361237403)), ('209.51.65.109', (8444, 1361237220)), ('63.234.48.142', (8444, 1361236793)), ('109.78.3.43', (8444, 1361225488)), ('81.249.180.30', (8444, 1361237427)), ('89.164.222.66', (8444, 1361232785)), ('189.103.118.122', (8444, 1361225953)), ('82.39.57.13', (8444, 1361230797)), ('206.45.25.137', (8444, 1361236608)), ('116.6.79.2', (8444, 1361236618)), ('46.165.208.107', (8444, 1361231992)), ('86.6.157.145', (8444, 1361227989)), ('70.194.131.158', (8444, 1361236013)), ('217.23.15.243', (8444, 1361223561)), ('99.175.208.136', (8444, 1361224895)), ('2.224.111.132', (8444, 1361235898)), ('124.78.182.24', (8444, 1361236508)), ('80.79.120.16', (8444, 1361232026)), ('84.48.88.49', (8444, 1361237169)), ('127.1.1.1', (8444, 1361236025)), ('50.129.211.39', (8444, 1361236830)), ('91.223.116.40', (8445, 1361232803)), ('96.241.16.20', (8444, 1361236770)), ('80.79.120.8', (8444, 1361229780)), ('192.211.53.106', (8444, 1361228142)), ('184.66.9.112', (8444, 1361236700)), ('83.90.164.116', (8444, 1361228584)), ('151.15.41.7', (8444, 1361237400)), ('96.44.189.102', (8444, 1361226439)), ('80.79.120.2', (8444, 1361228887)), ('98.116.124.198', (8444, 1361236798)), ('94.185.85.171', (8444, 1361229774)), ('60.234.54.74', (8444, 1361231207)), ('94.23.212.109', (8444, 1361226228)), ('67.168.198.22', (8444, 1361232515)), ('76.180.233.38', (8444, 1361237523)), ('184.75.213.114', (8444, 1361227826)), ('198.84.215.231', (8444, 1361236364)), ('66.108.210.244', (8080, 1361237314)), ('198.84.174.156', (8444, 1361236556)), ('109.123.79.189', (8444, 1361237335)), ('94.40.96.200', (8444, 1361229926)), ('93.136.20.229', (8444, 1361228783)), ('83.172.65.145', (8444, 1361235813)), ('216.67.170.48', (8444, 1361237306)), ('50.83.98.159', (8444, 1361237419)), ('1.4.226.61', (8444, 1361226274)), ('98.14.199.232', (8080, 1361225396)), ('213.236.204.50', (8444, 1361232982)), ('24.142.14.153', (8444, 1361237193)), ('74.132.73.137', (8444, 1361236900)), ('80.79.120.18', (8444, 1361229654)), ('95.211.136.17', (8444, 1361236597)), ('60.242.109.18', (8444, 1361237169)), ('193.190.147.190', (8444, 1361236381)), ('38.125.89.254', (8444, 1361226991)), ('80.79.120.25', (8444, 1361227758)), ('190.245.50.225', (8444, 1361236497)), ('173.54.22.118', (8444, 1361235293)), ('84.170.148.49', (8444, 1361225693)), ('80.79.120.23', (8444, 1361225023)), ('87.176.9.118', (8444, 1361223755)), ('76.106.160.76', (8444, 1361236866)), ('59.167.95.209', (8444, 1361237551)), ('76.120.71.166', (8444, 1361232451)), ('77.247.181.162', (8444, 1361226422)), ('69.113.14.186', (8444, 1361232697)), ('173.178.154.105', (8444, 1361234623)), ('98.154.221.132', (8444, 1361235764)), ('71.163.32.43', (8444, 1361236851)), ('217.235.218.125', (8444, 1361223903)), ('66.108.52.38', (8444, 1361237119)), ('70.30.61.17', (8444, 1361236939)), ('71.227.74.87', (8444, 1361237340)), ('96.47.226.20', (8444, 1361225924))]
Sending addr with 66 entries.
Sending huge inv message with 612 objects to just this one peer
remoteCommand addr from 59.167.95.209
addr message contains 1 IP addresses.
knownNodes currently has 81 nodes for this stream.
remoteCommand addr from 59.167.95.209
addr message contains 59 IP addresses.
knownNodes currently has 81 nodes for this stream.
self.sock.sendall failed
sendDataThread thread <main.sendDataThread object at 0x973b3ac> ending now
QThread: Destroyed while thread is still running
Segmentation fault
I have 3 message in queue to send.
I'm running on Fedora 17 (kernel 3.7.3-101.fc17.x86_64), Python 2.7, libssl 1.0.0, and I'm getting undefined symbol errors too. Except in my case it was EC_KEY_free. When I commented those lines out in pyelliptic/openssl.py, it was EC_KEY_new_by_curve_name.
Worked perfectly on my Ubuntu 12.04 box though.
I could be wrong, but I think the root of the problem is that in line 409, when it tries to do this:
It fails to find libcrypto.so, even though it is in /usr/lib64/
Because of that, it resorts to find_library('ssl') and gets libssl.so.10 instead of libcrypto.
I don't know much about OpenSSL but this is my best guess. Hope it helps.
Probably because your openssl does not have ECC support compiled in on your fedora box.
I obtain this error every time.. The only variance is the connection counter...
sendDataThread thread (associated with 95.241.108.5 ) ID: 3067141356 shutting down now.
len of sendDataQueues 9
QThread: Destroyed while thread is still running
Updating network status tab with current connections count: 9
QThread: Destroyed while thread is still running
Segmentation fault
Perhaps the Segmentation fault has a deeper cause and it simply causes the program to exit abruptly causing those "Thread destroyed while still running" messages. An early version of Bitmessage on OS X would Seg fault when the program was minimized to tray. Perhaps your client is Seg faulting because it is attempting to use an OpenSSL function.
It looks like ECC is left out of Fedora for patent reasons, and that's why
I'm getting those AttributeErrors. I'm looking into how to install it, but
to maximize portability, maybe this needs to be part of the application? Is
that feature critical to the operation of Bitmessage?
On Tue, Feb 19, 2013 at 2:03 AM, jasondz notifications@github.com wrote:
Benjamin J. Thompson
@Atheros1 No minimization done in taskbar. The message segfault appear randomly.
The taskbar minimization was only meant as an example.
Unfortunately I cannot troubleshoot the problem if it is not happening to me.
@BenjaminThompson Yes, ECC is critical to Bitmessage
I assume (for now) that I can legally include any compiled OpenSSL library along with the Bitmessage source code. But then this isn't exactly open source and I might as well just ship a fully compiled binary.
On Debian you will have to do a manual upgrade of openssl to a recent version such as 1.0.1 as described here... http://mariobrandt.de/archives/linux/upgrading-openssl-on-debian-6-squeeze-or-ubuntu-8-04-hardy-456/
I imagine you could do the same on Fedora.
I have Fedora 18 with openssl 1.0.1 and I get the same error.
I believe this is because on Fedora (and probably also Debian), that
library is compiled without certain features. I haven't found a convenient
way around that inconvenience yet. Bitmessage works without complaint on
Ubuntu 12.04.
On Wed, Mar 27, 2013 at 2:42 PM, Francesco Frassinelli <
notifications@github.com> wrote:
Benjamin J. Thompson
For everyone who don't want to install a new version of OpenSSL on their system, you can do it this way:
and then add to your ~/.bashrc
Well Bitmessage won't run on Debian6 anyway because it ships python2.6 only and Bitmessage needs at least python2.7, so upgrade python too or fail...
Aight I did it.
First we need sqlite3
Then we do python2.7. Make sure that at the end of make _sqlite3 is NOT in the list of missing modules!
We need to edit setup.py so python can find our fresh installed sqlite.
You may use PATH to use python2.7 command on userlevel. Open .bashrc again:
And set a symlink
Now Bitmessage working well. Just open it with
Doesn't work? Exit your bash and open it again to reload .bashrc settings.
Olaf
PS: Some1 wants to put this stuff to a wiki page? 8-)
FYI no manual work was required on Debian Wheezy, the new-ish current stable version.
I tested latest mailchuck fork on Debian 8.2 without problems. I also reworked the search for library a bit. If your python or openssl are too old I can't do much about it, but you should have a way of having an openssl library in a different directory to override the system one. I changed how the directory search order works so you may have better luck now. If it still doesn't work, use pyinstaller to bundle the correct openssl version, and then it should load it from the bundle.
debian 11
https://ibb.co/Rg8nJkX
Try the appimage: https://appimage.bitmessage.org/releases/