Problem starting Armory

[AliceWonderMiscreations]

Trying to run Armory on CentOS 7

Built from source as RPM by me - 0.93.2

Here's the error :

Code:

[alice@localhost ~]$ armory
(ERROR) announcefetch.py:312 - Could not verify data in signed message block
Traceback (most recent call last):
  File "/usr/libexec/armory/announcefetch.py", line 304, in __runFetchSequence
    sig, msg = readSigBlock(digestData)
  File "/usr/libexec/armory/jasvet.py", line 589, in readSigBlock
    name = r.split(BEGIN_MARKER)[1].split(DASHX5)[0]
IndexError: list index out of range
(ERROR) Traceback (most recent call last):
  File "/usr/libexec/armory/ArmoryQt.py", line 7158, in <module>
    form = ArmoryMainWindow(splashScreen=SPLASH)
  File "/usr/libexec/armory/ArmoryQt.py", line 822, in __init__
    self.setDashboardDetails()
  File "/usr/libexec/armory/ArmoryQt.py", line 5666, in setDashboardDetails
    sdmState = TheSDM.getSDMState()
  File "/usr/libexec/armory/SDM.py", line 752, in getSDMState
    state = self.getSDMStateLogic()
  File "/usr/libexec/armory/SDM.py", line 788, in getSDMStateLogic
    latestInfo = self.getTopBlockInfo()
  File "/usr/libexec/armory/SDM.py", line 925, in getTopBlockInfo
    if self.isRunningBitcoind():
  File "/usr/libexec/armory/SDM.py", line 725, in isRunningBitcoind
    self.btcOut, self.btcErr = self.bitcoind.communicate()
  File "/usr/lib64/python2.7/subprocess.py", line 800, in communicate
    return self._communicate(input)
  File "/usr/lib64/python2.7/subprocess.py", line 1396, in _communicate
    self.stdin.flush()
ValueError: I/O operation on closed file

Traceback (most recent call last):
  File "/usr/libexec/armory/ArmoryQt.py", line 7158, in <module>
    form = ArmoryMainWindow(splashScreen=SPLASH)
  File "/usr/libexec/armory/ArmoryQt.py", line 822, in __init__
    self.setDashboardDetails()
  File "/usr/libexec/armory/ArmoryQt.py", line 5666, in setDashboardDetails
    sdmState = TheSDM.getSDMState()
  File "/usr/libexec/armory/SDM.py", line 752, in getSDMState
    state = self.getSDMStateLogic()
  File "/usr/libexec/armory/SDM.py", line 788, in getSDMStateLogic
    latestInfo = self.getTopBlockInfo()
  File "/usr/libexec/armory/SDM.py", line 925, in getTopBlockInfo
    if self.isRunningBitcoind():
  File "/usr/libexec/armory/SDM.py", line 725, in isRunningBitcoind
    self.btcOut, self.btcErr = self.bitcoind.communicate()
  File "/usr/lib64/python2.7/subprocess.py", line 800, in communicate
    return self._communicate(input)
  File "/usr/lib64/python2.7/subprocess.py", line 1396, in _communicate
    self.stdin.flush()
ValueError: I/O operation on closed file

Here's how it is built

Code:

%build
sed -ie s?"\$(PREFIX)/lib/armory"?"\$(PREFIX)/libexec/armory"? Makefile
sed -ie s?"/usr/lib/armory"?"/usr/libexec/armory"? ArmoryQt.py
sed -ie s?"/usr/lib/armory"?"/usr/libexec/armory"? dpkgfiles/armory
sed -ie s?"/usr/lib/armory"?"/usr/libexec/armory"? osxbuild/Armory-script.sh
sed -ie s?"/usr/lib/armory"?"/usr/libexec/armory"? osxbuild/armoryd-script.sh
sed -ie s?"/usr/lib/armory"?"/usr/libexec/armory"? osxbuild/objc_armory/ArmoryMac.pro
sed -ie s?"/usr/lib/armory"?"/usr/libexec/armory"? release_scripts/Step2_Offline_PackageSigning.py
sed -ie s?"/usr/lib/armory"?"/usr/libexec/armory"? release_scripts/signannounce.py
sed -ie s?"/usr/lib/armory"?"/usr/libexec/armory"? release_scripts/README.txt
sed -ie 's/\r//' BitTornado/launchmanycore.py

make %{?_smp_mflags}


%install
make install DESTDIR=%{buildroot}

It does start bitcoind before that error occurs.

Any suggestions?

SELinux is disabled so that's not the issue.

Thank you

[AliceWonderMiscreations]

Whoa, wait, I'm running an old version? Why the frack doesn't the armory website list the new version if it was released all the way back in October?

That's um really odd.

[AliceWonderMiscreations]

Okay after checking out the 0.93.3 release and rebuilding the RPM, the same issue persists.

For what it's worth, bitcoin-qt works just fine.

I'm wondering if my python environment isn't as complete as it should be?

[achow101]

From that error message it looks like Armory is unable to verify the signed announcement messages.

Could you post your armory logs?

Also, it would be a good idea to submit a bug report to Armory by going to Help > Submit Bug Report in Armory.

[AliceWonderMiscreations]

Well that's interesting - I looked at the logs and saw this is the announcement it is trying to fetch -

2016-01-13 18:31 (INFO) -- announcefetch.py:271 - Fetching: https://bitcoinarmory.com/announce.txt?osvar=centos+linux&os=lin&ver=0.93.3&id=d4cdcaba

When I grabbed that with wget and looked, it appears to grab a wordpress press including crap like googleapi javascript. What the hell is it doing that for?

Here's the log -

http://awel.domblogger.net/7/libre/armorylog.txt

[AliceWonderMiscreations]

I also have to ask, does this mean that a DoS attack on the armory website means armory stops working because clients can't get the signed messages it seems unable to start without?

[AliceWonderMiscreations]

Here is attempting to start it skipping the announce check

Code:

[alice@localhost ~]$ armory --skip-announce-check
(ERROR) Traceback (most recent call last):
  File "/usr/libexec/armory/ArmoryQt.py", line 7147, in <module>
    form = ArmoryMainWindow(splashScreen=SPLASH)
  File "/usr/libexec/armory/ArmoryQt.py", line 822, in __init__
    self.setDashboardDetails()
  File "/usr/libexec/armory/ArmoryQt.py", line 5655, in setDashboardDetails
    sdmState = TheSDM.getSDMState()
  File "/usr/libexec/armory/SDM.py", line 752, in getSDMState
    state = self.getSDMStateLogic()
  File "/usr/libexec/armory/SDM.py", line 788, in getSDMStateLogic
    latestInfo = self.getTopBlockInfo()
  File "/usr/libexec/armory/SDM.py", line 925, in getTopBlockInfo
    if self.isRunningBitcoind():
  File "/usr/libexec/armory/SDM.py", line 725, in isRunningBitcoind
    self.btcOut, self.btcErr = self.bitcoind.communicate()
  File "/usr/lib64/python2.7/subprocess.py", line 800, in communicate
    return self._communicate(input)
  File "/usr/lib64/python2.7/subprocess.py", line 1396, in _communicate
    self.stdin.flush()
ValueError: I/O operation on closed file

Traceback (most recent call last):
  File "/usr/libexec/armory/ArmoryQt.py", line 7147, in <module>
    form = ArmoryMainWindow(splashScreen=SPLASH)
  File "/usr/libexec/armory/ArmoryQt.py", line 822, in __init__
    self.setDashboardDetails()
  File "/usr/libexec/armory/ArmoryQt.py", line 5655, in setDashboardDetails
    sdmState = TheSDM.getSDMState()
  File "/usr/libexec/armory/SDM.py", line 752, in getSDMState
    state = self.getSDMStateLogic()
  File "/usr/libexec/armory/SDM.py", line 788, in getSDMStateLogic
    latestInfo = self.getTopBlockInfo()
  File "/usr/libexec/armory/SDM.py", line 925, in getTopBlockInfo
    if self.isRunningBitcoind():
  File "/usr/libexec/armory/SDM.py", line 725, in isRunningBitcoind
    self.btcOut, self.btcErr = self.bitcoind.communicate()
  File "/usr/lib64/python2.7/subprocess.py", line 800, in communicate
    return self._communicate(input)
  File "/usr/lib64/python2.7/subprocess.py", line 1396, in _communicate
    self.stdin.flush()
ValueError: I/O operation on closed file

So it seems there is more than one problem.

These are from the log file just before that -

Code:

2016-01-14 03:48 (INFO) -- ArmoryUtils.py:600 - Executing popen: gconftool-2 --get /desktop/gnome/url-handlers/bitcoin/command
2016-01-14 03:48 (INFO) -- ArmoryUtils.py:600 - Executing popen: xdg-mime query default x-scheme-handler/bitcoin
2016-01-14 03:48 (INFO) -- ArmoryUtils.py:600 - Executing popen: find /home/alice -type f -name "mimeTypes.rdf"
2016-01-14 03:48 (INFO) -- ArmoryQt.py:664 - Usermode: Advanced
2016-01-14 03:48 (INFO) -- ArmoryQt.py:1810 - Changing usermode:
2016-01-14 03:48 (INFO) -- ArmoryQt.py:1811 -    From: Advanced
2016-01-14 03:48 (INFO) -- ArmoryQt.py:1819 -      To: Advanced

[AliceWonderMiscreations]

With the debug switch -

Code:

(DEBUG) ArmoryQt.py:2474 - Bitcoind started without error
(DEBUG) ArmoryQt.py:1411 - setupSystemTray
(DEBUG) SDM.py:844 - Creating proxy
(INFO) SDM.py:848 - Creating proxy in SDM: host=127.0.0.1, port=8332
(DEBUG) SDM.py:891 - generic socket error
(DEBUG) SDM.py:723 - Bitcoind is no more
(INFO) ArmoryQt.py:1514 - setupUriRegistration
(INFO) ArmoryUtils.py:600 - Executing popen: gconftool-2 --get /desktop/gnome/url-handlers/bitcoin/command
(INFO) ArmoryUtils.py:600 - Executing popen: xdg-mime query default x-scheme-handler/bitcoin
(INFO) ArmoryUtils.py:600 - Executing popen: find /home/alice -type f -name "mimeTypes.rdf"
(DEBUG) ArmoryQt.py:4350 - setupDashboard
(INFO) ArmoryQt.py:664 - Usermode: Advanced
(INFO) ArmoryQt.py:1810 - Changing usermode:
(INFO) ArmoryQt.py:1811 -    From: Advanced
(INFO) ArmoryQt.py:1819 -      To: Advanced
(DEBUG) SDM.py:723 - Bitcoind is no more

I turned off firewalld just to make sure that wasn't the issue, same thing.
It seems to be starting bitcoind without error but debug seems to be indication a "generic socket error" followed by "Bitcoind is no more" (yet it is still running according to ps aux)

[josephbisch]

Well that's interesting - I looked at the logs and saw this is the announcement it is trying to fetch -

2016-01-13 18:31 (INFO) -- announcefetch.py:271 - Fetching: https://bitcoinarmory.com/announce.txt?osvar=centos+linux&os=lin&ver=0.93.3&id=d4cdcaba

When I grabbed that with wget and looked, it appears to grab a wordpress press including crap like googleapi javascript. What the hell is it doing that for?

Here's the log -

http://awel.domblogger.net/7/libre/armorylog.txt

When you navigate to that URL, you are redirected to the bitcoinarmory.com homepage. If you get rid of the parameters (the ? and everything after it) you get announce.txt as Armory is expecting. The reason Armory isn't running for you is that the program is expecting to receive a Bitcoin Signed Message, but is receiving the Armory homepage.

[AliceWonderMiscreations]

Well that's interesting - I looked at the logs and saw this is the announcement it is trying to fetch -

2016-01-13 18:31 (INFO) -- announcefetch.py:271 - Fetching: https://bitcoinarmory.com/announce.txt?osvar=centos+linux&os=lin&ver=0.93.3&id=d4cdcaba

When I grabbed that with wget and looked, it appears to grab a wordpress press including crap like googleapi javascript. What the hell is it doing that for?

Here's the log -

http://awel.domblogger.net/7/libre/armorylog.txt

When you navigate to that URL, you are redirected to the bitcoinarmory.com homepage. If you get rid of the parameters (the ? and everything after it) you get announce.txt as Armory is expecting. The reason Armory isn't running for you is that the program is expecting to receive a Bitcoin Signed Message, but is receiving the Armory homepage.

Okay I am trying with the --skip-announce-check option to avoid that single point of failure (really dumb IMHO to make startup depend upon a specific URL responding in a specific way - what problem are they trying to solve ) and that is no longer an issue, but now it seems to have issues with creating a socket to the bitcoind service.

[AliceWonderMiscreations]

Code:

def __backgroundRequestTopBlock(self):

That's the function in SDM.py where the socket.error is triggering.

It's possible this is actually a problem with bitcoind but I don't know how to determine that.

When building bitcoin-core I ran:

Code:

%check
# Run all the tests
make check
# Run all the other tests
pushd src
srcdir=. test/bitcoin-util-test.py
popd
qa/pull-tester/rpc-tests.sh -extended

which takes a really long time but all tests passed.

[Carlton Banks]

Try turning off the bitcoind auto-management option from the settings (or in the config file the settings store).

Also, be sure to use 93.3, as 93.2 suffers a bug that could cause your transactions to fail.

[AliceWonderMiscreations]

Try turning off the bitcoind auto-management option from the settings (or in the config file the settings store).

Also, be sure to use 93.3, as 93.2 suffers a bug that could cause your transactions to fail.

I can't even get to the damn settings, it doesn't get that far.

I am using 93.3 now - initially I was using 93.2 because for some reason I can't comprehend, they don't have 93.3 listed on their website *and* they don't have an archive of release tarballs.

It is feeling like this is a project where the developer has become bored and doesn't want to do it anymore.

[AliceWonderMiscreations]

I was not happy to see btw that by default an application that claims security as a motive reports both the operating system and version of the operating system to the projects homepage. That's not cool.

Even worse, it does it in a get variable. It has the full facilities of python at its disposal, at least do it via post if you must do it at all.

I think I am just going to stick with bitcoin-core.

It works and will continue to work and I don't risk issues where an upgrade to the product breaks the ability to even use my wallet, bitcoin-core is well tested before release and old versions are easy to get if needed via source tarballs with a checksum.

The deterministic wallet and cold-address management is a nice thing to have, but it looks like armory is suffering from feature bloat instead of embracing KISS.

And from the reading the forum, it appears the developer now is focusing on a closed source project.

Ah well.

I used armory for awhile in Fedora a little over a year ago and really liked it.

[Carlton Banks]

I think there are archived versions of releases with any major format changes, but the URL's are not well advertised as new releases have always been more or less unanimous improvements over their predecessors (only those searching hard ever need to find those links I guess).

As for the state of the project... well, 93.3 was put out under different circumstances to previous releases, but there's no word yet from etotheipi on what the reason for that was. The 93.3 fix had to be pushed out quickly anyway (to correctly ameliorate the network problem for Armory users that the 0.11.1 tx malleability fix provided), which is a possible reason for the way that release was handled.

The only other publicly available information is that Mac/OSX support was shelved at that time, but then quickly reinstated with the help of a Mac user who submitted a fix on this sub. From that, a reasonable conclusion would be that they've lost a developer who provided all OSX efforts. But that's all based on a supposition.

[AliceWonderMiscreations]

I think it needs to get back to the fundamentals.

Hierarchal Deterministic Wallet

Cold Address Management

Watch Only Wallets

Focus on doing those things and doing those things correctly, and without having the product calling home. That's ridiculous. I don't think it use to do that, that seems to be a new "feature".

Then allow other features people want (e.g. multisig) to be option plugin add-ons.

-=-

It's like OpenSSL - bugs like heartbleed happened because of feature creep. No one even needs the heartbeat extension, seriously. Who the hell does TLS over UDP?

Yet they put it in enabled by default and people who had no user for it had their certificates compromised as a result.

Keep things simple, Armory needs to get back to that in my opinion. Maybe it needs a fork.

[achow101]

I think it needs to get back to the fundamentals.

Hierarchal Deterministic Wallet

Cold Address Management

Watch Only Wallets

Focus on doing those things and doing those things correctly, and without having the product calling home. That's ridiculous. I don't think it use to do that, that seems to be a new "feature".

Then allow other features people want (e.g. multisig) to be option plugin add-ons.

AFAIK calling home has been a function in armory for a while so that you can get announcements and updates. It shouldn't break anything or cause problems since offline mode can't get the announcements. I think there is some other problem here, but I haven't had the time to look at your logs.

Can you also post the armorycpplog file?

[AliceWonderMiscreations]

Well it means anyone who gets access to the server logs now has a list of IP addresses corresponding with operating system and OS version of people who use bitcoin.

That should never have happened.

[goatpig]

Well it means anyone who gets access to the server logs now has a list of IP addresses corresponding with operating system and OS version of people who use bitcoin.

That should never have happened.

We make a point of not logging the IPs, but that boils down to a trust relationship. If you choose not to trust that, turn off the feature. There are also options to run specifically through Tor if you want to hide your IP. You should evaluate settings in Armory against Bitcoin's own network model. Anyone controlling and/or monitoring a lot of nodes has a good chance to figure out your IP.

The counterpart to this "phoning home" feature is that we get an channel to push critical announcements to our users (something both Core and Armory need and have used in the past). We piggy back on Core for our networking purposes. We won't abide by a network policy Core doesn't respect, that would make no sense.

Again if you dislike this feature, you can turn it off. If you want to change your settings before letting Armory connect to anything, you should first start it in offline mode.

------------------------

Going back to your problem, Armory is trying to start bitcoind and failing. That's a default "easy mode" feature that you should probably turn off since we do not officially support CentOS. To do this, start Armory in offline mode and go to File -> Settings. Uncheck the first check box. Then start BitcoinQt manually and restart Armory.

[AliceWonderMiscreations]

Instead of putting the OS variant etc. into a GET variable, why not just have the server respond with a generic XML file that has the current version for each OS?

Then the client can look through the XML file (or whatever) to see what the current version is. If it is newer than what is running, the user gets an alert that they may want to upgrade.

No information about the running environment is leaked that way.

[goatpig]

Instead of putting the OS variant etc. into a GET variable

The GET vs POST distinction is irrelevant with SSL

why not just have the server respond with a generic XML file that has the current version for each OS?

Then the client can look through the XML file (or whatever) to see what the current version is. If it is newer than what is running, the user gets an alert that they may want to upgrade.

We already do that. The calling back home part is a story on its own. There is a thread about this, what it used to do, and what it has changed to after the community complained about the type of content being sent to our servers. You should dig that up. I don't remember what the conclusion was (it was over a year ago), but I believe the community was satisfied with the changes.

What you should really be asking for is a dialogue showing up at Armory's startup with a warning that it wants to phone home and an option to change the setting with all the warnings, caveats, DNAA and all that stuff.

[AliceWonderMiscreations]

Instead of putting the OS variant etc. into a GET variable

The GET vs POST distinction is irrelevant with SSL

No it is not. GET variables end up in the server log files, POST data submissions do not.

[achow101]

Instead of putting the OS variant etc. into a GET variable

The GET vs POST distinction is irrelevant with SSL

No it is not. GET variables end up in the server log files, POST data submissions do not.

How so? I think it is fairly trivial to log all the details of both GET and POST requests.

We already do that. The calling back home part is a story on its own. There is a thread about this, what it used to do, and what it has changed to after the community complained about the type of content being sent to our servers. You should dig that up. I don't remember what the conclusion was (it was over a year ago), but I believe the community was satisfied with the changes.

What you should really be asking for is a dialogue showing up at Armory's startup with a warning that it wants to phone home and an option to change the setting with all the warnings, caveats, DNAA and all that stuff.

I believe this was the post with the solution: https://bitcointalk.org/index.php?topic=731315.msg8299712#msg8299712

[AliceWonderMiscreations]

GET variables are part of the requested URI and therefore logging them is standard. It is very unusual for them NOT to be in the typical access / error log. POST - I suppose it technically is possible for them to be logged, you can log anything, but I have never seen a server put POST data in the standard access / error logs. GET - I've never seen a server that doesn't.

The log files thus because a source of information, and often times when a remote log server is used, access to log files can be achieved without rooting the specific server handling the requests.

Log files are also often viewed by a multitude of different system administrators and sometimes even third party contractors, especially with support requests.

As such, data that can be considered sensitive should never be used in GET variables.

What distribution of what OS a user is running certainly counts.

[goatpig]

I believe this was the post with the solution: https://bitcointalk.org/index.php?topic=731315.msg8299712#msg8299712

It is.

GET variables are part of the requested URI and therefore logging them is standard. It is very unusual for them NOT to be in the typical access / error log. POST - I suppose it technically is possible for them to be logged, you can log anything, but I have never seen a server put POST data in the standard access / error logs. GET - I've never seen a server that doesn't.

The log files thus because a source of information, and often times when a remote log server is used, access to log files can be achieved without rooting the specific server handling the requests.

Log files are also often viewed by a multitude of different system administrators and sometimes even third party contractors, especially with support requests.

As such, data that can be considered sensitive should never be used in GET variables.

What distribution of what OS a user is running certainly counts.

I'll look into changing it to POST for the next version.

[AliceWonderMiscreations]

I would like to apologize.

I believe I was making a mountain out of a molehill.

-=-

For the Armory RPM I am packaging for my LibreLAMP project - I will be doing the following :

Code:

sed -ie s?"^Exec=.*"?"Exec=/usr/bin/armory --skip-announce-check"? dpkgfiles/armory.desktop

As it is in a yum repository, updating through yum will be the right way to do it anyway, and so turning off the announce check makes sense both from that perspective and from the privacy perspective.

I would still prefer the data be sent by post. But I think I was too aggressive in my stance.

-=-

Armory is still broken on CentOS 7 but the problem may actually be related to my build of bitcoind - the problem is a socket error, and I'm building bitcoind against LibreSSL.

So I want to test it built using OpenSSL to see if there's a difference.

[Carlton Banks]

Armory is still broken on CentOS 7 but the problem may actually be related to my build of bitcoind - the problem is a socket error, and I'm building bitcoind against LibreSSL.

So I want to test it built using OpenSSL to see if there's a difference.

Using the specific OpenSSL release prescribed by the Bitcoin developers is imperative apparently. I think the best case would be that the test node might reject signatures created by the regular clients using OpenSSL 1.0.1k, the worst might be the build failing (fairly sure there was a check put into the build file for 0.11, but maybe you're not using that). I'd definitely eliminate guaranteed problems like that first.

[AliceWonderMiscreations]

Armory is still broken on CentOS 7 but the problem may actually be related to my build of bitcoind - the problem is a socket error, and I'm building bitcoind against LibreSSL.

So I want to test it built using OpenSSL to see if there's a difference.

Using the specific OpenSSL release prescribed by the Bitcoin developers is imperative apparently. I think the best case would be that the test node might reject signatures created by the regular clients using OpenSSL 1.0.1k, the worst might be the build failing (fairly sure there was a check put into the build file for 0.11, but maybe you're not using that). I'd definitely eliminate guaranteed problems like that first.

The OpenSSL must have EC support OpenSSL in CentOS 7 does not but I know how to build an OpenSSL that works for building bitcoin-core that installs in parallel, I just prefer LibreSSL over OpenSSL in general.

Not only does the openssl with proper support install in parallel, but in the mock build system it's devel files would be the only openssl devel files installed so it would be impossible for bitcoin-core to accidentally link against the wrong one.

However I prefer LibreSSL - I think the OpenSSL project is bloated and buggy.

-=-

The current bitcoin-core builds against LibreSSL but you have to use a switch specifying --with-libressl

With that switch, it compiles successfully. Without that switch, it exist during configure. The qt client is able to validate blocks and create transactions that are accepted by other nodes. The bitcoind daemon is able to validate blocks, but I have not tried creating transactions with it yet.

However it is possible there is a bug with bitcoind accepting connections from other processes (such as armory) when built against LibreSSL, that is what I need to figure out.

EDIT

It should be noted that LibreSSL is API compatible with OpenSSL 1.0.1 - but there are sometimes bugs in software that uses that API that don't show up when building against OpenSSL. That's what may be going on here, a bug in bitcoin-core socket handling that doesn't show up when using OpenSSL but does show up when using LibreSSL.

[goatpig]

I would still prefer the data be sent by post. But I think I was too aggressive in my stance.

It's a good suggestion and I'm wondering why we using GET instead of POST now. I'll look into it. It's not that the change is difficult or anything, it's more an issue of logistics (I don't have access to the server, have to explain the why and how of that change to the other devs, make a ticket, document the process, all that stuff).

As it is in a yum repository

Are you saying you didn't build Armory from source? Let me make this clear: we do not officially support CentOS. You will not find any packages we signed for that OS. And for what it's worth, I have no idea who built the Armory on the repo you are using.

Armory is still broken on CentOS 7 but the problem may actually be related to my build of bitcoind - the problem is a socket error, and I'm building bitcoind against LibreSSL.

Is OpenSSL used in any way by the P2P layer in Core? I thought it was only for crypto. Did you consider the libsecpk1 branches? Anyways, I'd check permissions and security settings first, and I'd also make sure Python twisted works properly.

[AliceWonderMiscreations]

I did build Armory from source.

I created the src.rpm and I run the yum repository that it will eventually be in.

Here's the src.rpm

http://awel.domblogger.net/7/libre/src/repoview/bitcoin-armory.html

No binary RPMs yet because it isn't working (but does build).

Here's the bitcoin core src.rpm

http://awel.domblogger.net/7/libre/src/repoview/bitcoin.html

(I do have binary for it too) - it is based on the RingingLiberty repo src.rpm but modified to build against LibreSSL

[Carlton Banks]

EDIT

It should be noted that LibreSSL is API compatible with OpenSSL 1.0.1 - but there are sometimes bugs in software that uses that API that don't show up when building against OpenSSL. That's what may be going on here, a bug in bitcoin-core socket handling that doesn't show up when using OpenSSL but does show up when using LibreSSL.

Not sure if I was clear enough, that's what I meant (but not your bug, the core developers state that the ECDSA code specifically exhibits differing behaviour between OpenSSL versions). Definitely ditch LibreSSL IMO.

[AliceWonderMiscreations]

EDIT

It should be noted that LibreSSL is API compatible with OpenSSL 1.0.1 - but there are sometimes bugs in software that uses that API that don't show up when building against OpenSSL. That's what may be going on here, a bug in bitcoin-core socket handling that doesn't show up when using OpenSSL but does show up when using LibreSSL.

Not sure if I was clear enough, that's what I meant (but not your bug, the core developers state that the ECDSA code specifically exhibits differing behaviour between OpenSSL versions). Definitely ditch LibreSSL IMO.

Well I would rather keep using bitcoin-qt than ditch LibreSSL.

I am very committed to LibreSSL and am very annoyed at the OpenSSL development process, which seems to be more about getting money from the FIPS consulting than anything else these days.

If bitcoin-qt didn't work with LibreSSL (as it didn't until recently) then I would have no choice, but since bitcoin-qt does work with LibreSSL then I have a choice, and that choice is to ditch OpenSSL wherever possible.

That's why I run a CentOS 7 yum repository based on LibreSSL with lots of different software rebuilt against LibreSSL. I don't trust the OpenSSL library to be secure.

[AliceWonderMiscreations]

With OpenSSL heartbleed wasn't what prompted the fork to LibreSSL, it was the final straw.

There were undisputed bugs in OpenSSL for years, in their bug-tracking system, with patches submitted to fix them, that were ignored by the OpenSSL developers while the OpenSSL developers continued to add new (sometimes dangerous) features, including heartbeat.

That's what prompted the fork.

OpenSSL post fork has cleaned up a bit, in response to the fork, but I still don't trust their development process. If that means a little patience is required before I can run armory (and I'm not sure that is actually the issue yet) then I will just have a little more patience. Not a biggie.

[achow101]

EDIT

It should be noted that LibreSSL is API compatible with OpenSSL 1.0.1 - but there are sometimes bugs in software that uses that API that don't show up when building against OpenSSL. That's what may be going on here, a bug in bitcoin-core socket handling that doesn't show up when using OpenSSL but does show up when using LibreSSL.

Not sure if I was clear enough, that's what I meant (but not your bug, the core developers state that the ECDSA code specifically exhibits differing behaviour between OpenSSL versions). Definitely ditch LibreSSL IMO.

Well I would rather keep using bitcoin-qt than ditch LibreSSL.

I am very committed to LibreSSL and am very annoyed at the OpenSSL development process, which seems to be more about getting money from the FIPS consulting than anything else these days.

If bitcoin-qt didn't work with LibreSSL (as it didn't until recently) then I would have no choice, but since bitcoin-qt does work with LibreSSL then I have a choice, and that choice is to ditch OpenSSL wherever possible.

That's why I run a CentOS 7 yum repository based on LibreSSL with lots of different software rebuilt against LibreSSL. I don't trust the OpenSSL library to be secure.

Bitcoin Core is moving off of OpenSSL when 0.12 is released in a few weeks. Instead they will be using their own libsecp256k1 library for all EC operations which will be faster than using OpenSSL. That may also fix your problems.

[AliceWonderMiscreations]

EDIT

It should be noted that LibreSSL is API compatible with OpenSSL 1.0.1 - but there are sometimes bugs in software that uses that API that don't show up when building against OpenSSL. That's what may be going on here, a bug in bitcoin-core socket handling that doesn't show up when using OpenSSL but does show up when using LibreSSL.

Not sure if I was clear enough, that's what I meant (but not your bug, the core developers state that the ECDSA code specifically exhibits differing behaviour between OpenSSL versions). Definitely ditch LibreSSL IMO.

Well I would rather keep using bitcoin-qt than ditch LibreSSL.

I am very committed to LibreSSL and am very annoyed at the OpenSSL development process, which seems to be more about getting money from the FIPS consulting than anything else these days.

If bitcoin-qt didn't work with LibreSSL (as it didn't until recently) then I would have no choice, but since bitcoin-qt does work with LibreSSL then I have a choice, and that choice is to ditch OpenSSL wherever possible.

That's why I run a CentOS 7 yum repository based on LibreSSL with lots of different software rebuilt against LibreSSL. I don't trust the OpenSSL library to be secure.

Bitcoin Core is moving off of OpenSSL when 0.12 is released in a few weeks. Instead they will be using their own libsecp256k1 library for all EC operations which will be faster than using OpenSSL. That may also fix your problems.

Yes, I've found that library on github and actually have done a little playing with an experimental PHP module that links against it.

Moving to that library is the right thing to do IMHO.

[Carlton Banks]

Well I would rather keep using bitcoin-qt than ditch LibreSSL.

I am very committed to LibreSSL and am very annoyed at the OpenSSL development process, which seems to be more about getting money from the FIPS consulting than anything else these days.

If bitcoin-qt didn't work with LibreSSL (as it didn't until recently) then I would have no choice, but since bitcoin-qt does work with LibreSSL then I have a choice, and that choice is to ditch OpenSSL wherever possible.

That's why I run a CentOS 7 yum repository based on LibreSSL with lots of different software rebuilt against LibreSSL. I don't trust the OpenSSL library to be secure.

You're trying to convert a missionary here, I'm also inclined toward LibreSSL after the problems with OpenSSL (and well done for putting it together incidentally, it must have been challenging whichever way you approached it).

But not for this one purpose, it's part of the consensus driven code base. With crypto-driven consensus, correctness is not important if there's a practical reason to stick with incorrectness in respect of long-term development goals (like the Core developed in-house libsecp256k1 library mentioned by knightdk, that's been several years in the making now and only just about to see a release)