Topic: Armory - Discussion Thread - page 41. (Read 521749 times)

Hi guys,

i have a bug in Armory and this is annoying cuz im just waiting for a transaction now.

Armory Version : 0.91.2 x64
Windows 7

What i see first is Armory disconnect / Reconnect every 5 second.

I check on the web and i found some people with the same issue, but in majority of time they repair it with adding memory or get a faster hard drive.

In my case its not the problem, i have 32Go of Ram and two SSD Hard-drive in RAID 1.

When i check the log file this is an example of what is see :

2014-06-25 23:02 (INFO) -- ArmoryQt.py:5672 - Dashboard switched to fully-online mode
2014-06-25 23:02 (INFO) -- ArmoryQt.py:4986 - Switching Armory state text to Mgmt:User, State:OnlineFull1
2014-06-25 23:02 (INFO) -- ArmoryQt.py:4928 - Switching Armory functional mode to "Online"
2014-06-25 23:02 (INFO) -- ArmoryQt.py:4986 - Switching Armory state text to Mgmt:User, State:OnlineFull2
2014-06-25 23:02 (INFO) -- ArmoryQt.py:5552 - Dashboard switched to auto-InitSync
2014-06-25 23:02 (WARNING) -- ArmoryQt.py:4919 - Called updateSyncProgress while not sync'ing
2014-06-25 23:02 (INFO) -- ArmoryQt.py:4986 - Switching Armory state text to Mgmt:Auto, State:InitializingDoneSoon
2014-06-25 23:02 (INFO) -- ArmoryQt.py:4986 - Switching Armory state text to Mgmt:Auto, State:NewUserInfo
2014-06-25 23:02 (INFO) -- ArmoryQt.py:4928 - Switching Armory functional mode to "Offline"
2014-06-25 23:02 (INFO) -- ArmoryQt.py:5672 - Dashboard switched to fully-online mode
2014-06-25 23:02 (INFO) -- ArmoryQt.py:4986 - Switching Armory state text to Mgmt:User, State:OnlineFull1
2014-06-25 23:02 (INFO) -- ArmoryQt.py:4928 - Switching Armory functional mode to "Online"
2014-06-25 23:02 (INFO) -- ArmoryQt.py:4986 - Switching Armory state text to Mgmt:User, State:OnlineFull2
2014-06-25 23:02 (INFO) -- ArmoryQt.py:5552 - Dashboard switched to auto-InitSync
2014-06-25 23:02 (WARNING) -- ArmoryQt.py:4919 - Called updateSyncProgress while not sync'ing
2014-06-25 23:02 (INFO) -- ArmoryQt.py:4986 - Switching Armory state text to Mgmt:Auto, State:InitializingDoneSoon
2014-06-25 23:02 (INFO) -- ArmoryQt.py:4986 - Switching Armory state text to Mgmt:Auto, State:NewUserInfo
2014-06-25 23:02 (INFO) -- ArmoryQt.py:4928 - Switching Armory functional mode to "Offline"
2014-06-25 23:02 (INFO) -- ArmoryQt.py:5672 - Dashboard switched to fully-online mode
2014-06-25 23:02 (INFO) -- ArmoryQt.py:4986 - Switching Armory state text to Mgmt:User, State:OnlineFull1
2014-06-25 23:02 (INFO) -- ArmoryQt.py:4928 - Switching Armory functional mode to "Online"
2014-06-25 23:02 (INFO) -- ArmoryQt.py:4986 - Switching Armory state text to Mgmt:User, State:OnlineFull2
2014-06-25 23:02 (INFO) -- ArmoryQt.py:5552 - Dashboard switched to auto-InitSync
2014-06-25 23:02 (WARNING) -- ArmoryQt.py:4919 - Called updateSyncProgress while not sync'ing
2014-06-25 23:02 (INFO) -- ArmoryQt.py:4986 - Switching Armory state text to Mgmt:Auto, State:InitializingDoneSoon
2014-06-25 23:02 (INFO) -- ArmoryQt.py:4986 - Switching Armory state text to Mgmt:Auto, Stat

So i tried a couple of thing to try to understand the bug, but this just give me more question 

When i reboot my computer and just run Armory everything working fine.

But if i start Google Chrome and go On Gmail, Armory Disconnect

I do not understand but i can reproduce the bug like that.


Link: http://youtu.be/Q8Vve_VbvL8

The wallet don't disconnect only on Gmail, this is just an example. When i have a lot of program open the wallet bug to.

If i just restart the computer start Armory and do nothing he stay connected for some hour, but when i start app he start disconnecting.

After reproduce the bug a couple of time the Wallet connection start spiking. Connect / Disconnect every 5 Sec.

Here a Link to my Full log with the Spiking bug : http://pastebin.com/e0X0Ts4w

Thanks in advance for your help

Are there any plans on making Armory compatible with BIP70 and BIP72 compatible? It would be awesome if Armory downloaded and verified the payment request when a bitcoin URI with an r parameter was clicked. Also great would be if Armory could create signed payment requests, given the specified X509 certificate.

If there are no plans, would you accept pull requests for those features?

Alan is out of town so I'll try to fill in on these

a) Yes, we should have this ironed out by the next release, which is soon btw

b) I dont remember the exact details but this what happened: We used urllib3 for the overhauled announce system. We then realized most users won't have it so we decided to bundle urllib3 with the installers. Im not sure about how it unfolded from that point onwards since I wasn't involved with this part of the development, but the best solution we had resulted in dropping Python 2.6 support, which is what 10.xx ships with.

Of course, that lib is for online Armory, and could be entirely disabled for offline bundles, however that would require modifying the release process some more, which we aren't sure we want to delve in for now. So there's no definitive answer to this question, yet.

Ideally, we want to keep supporting older OS for at least offline Armory, such as 10.xx and XP, but only if doesn't come at the cost of ridiculous development efforts. The best way for you to avoid all this uncertainty would be to upgrade, indeed.

Two questions:

a) any plans to make available an offline bundle for Ubuntu 12.04.4?
b) are the offline bundles for 10.04 deprecated? Should we update our offline systems to 12.04?

I can confirm this behavior. I just tried the Secure Downloader on Windows 7 x64 in Armory 0.91.2-beta and the filename proposed in the "Save as..." dialouge was "armory_0.91.2-rc1_winAll.exe.signed.exe,". Without the "offline-verifiable signature" checkbox it's "armory_0.91.2-rc1_winAll.exe".

I'm sure I didn't accidentally typed the comma since I've double and triple checked. I have now upgraded to 0.91.2 on Windows and tried the same procedure, saving the Ubuntu installer with offline-verifiable signature and get the same .exe, file name suggested by Armory.
If I keep the "offline-verifiable signature" checkbox unchecked, the file is by default saved as:

I haven't tested the downloader on Ubuntu since that computer is offline

I'll make sure to give this some TLC before the next release.  Obviously the comma is an error.  And obviously it should show you .exe/.deb/etc in the file select dialog.  Also, try clicking "No" for overwriting and then click the button on the small dialog to specify where to save it.   

EDIT:  I just tested this on my linux box, and I didn't run into either problem.  When you do the download originally, it asks you where you want to save it.  Are you sure you didn't accidentally type a comma in there?  And you didn't see it on the list because of the comma -- it definitely shows you all ".signed" files, but not ".signed," files (with a comma).

I'm using Armory 0.91.1 on Windows 8.1 to download 0.91.2 (Testing unstable) 64-bit for Ubuntu 14.04 using Secure Downloader. When checking "Save with offline-verifiable signature" the file is saved as:
I didn't expect an exe file and it looks weird ending with a comma.

Next I select Verify Signed Package and select the file. I have to manually change to display all file types since there's no *.signed file. Armory asks me if I'd like to overwrite the original file to which I selected Yes. Armory explains that the installer was extracted to the same location (armory_0.91.2-rc1_ubuntu-64bit.deb.signed.exe,) however that file is now missing. It seems Armory removed the .exe, file but didn't extract any installer first.

Now I'm back at the Verify Signed Package window where I click "Select file to save to...". Now Armory suggests a file name of armory_0.91.2-rc1_ubuntu-64bit.deb.

Consistency makes sure that your addresses were all generated from the root key to make sure you can generate the private key

I just updated to 0.91.2 - thank you bitpop and etotheipifor for fast clarification, all is fine now.

Another question about the new Wallet Consistency Check: xx%  
What exactly is being checked here at this point? - Wallet Consistency Check finishes quite fast in around 30 seconds here.
Thanks

Bummer!  When I updated the torrent and re-signed the installer hashes, I accidentally left the "Testing (Unstable)" on 0.91.2 which is what is shown in the secure downloader.  I'll have to fix that.

On the other hand, it's listed on our website as the latest stable version.  So there's that...

No unless wallet has a new version and you created a new one

You should use 912 tho it's not unstable as it says

Hi

I upgraded from Armory 0.90 directly to 0.91.2, all went fine ( on a win 8.1 64bit OS )
When I realized that 0.91.2 is the "Armory Testing (unstable) 0.91.2" version
I simply installed  Armory 0.91.1 over 0.91.2, and it worked.

My question is, will I run into any issues because I installed an older version 0.91.1 over the newer one 0.91.2 ?

Thanks for clarification.

That might explain why the estimates are grossly inaccurate on an IO-bound virtual machine.

I just experienced a 31 minute wait to start up, when it had less than 3 days worth of new blocks to process.

"Time Remaining" never exceeded 2 minutes.

One thing I've learned over the course of building Armory is that those time-remaining bars are very difficult to get right.  Especially when it comes to things like downloading data that fluctuates in speed rapidly.   I have an extensive background in signal processing, yet I still can't get it right.

On the other hand ,there is a flaw in my algorithm -- it seems to use CPU-timings instead of wall-timings.  Typically this results in the system reporting that it took 2 sec to move 1% of the bar, instead of 3.2 or whatever.  This leads to very optimistic estimates.  I've been meaning to go in and figure out what is causing that, but I haven't had it on my priority list for a while.

Sometimes it feels like you used the "time remaining" algorithm from Windows 95, such as when the database rebuild progress displays 1.5 minutes remaining for 10 minutes.

THX for the hint. I will dig into that.

Wow, I missed out on some fun discussions.  Let me clarify how this works, and what Armory has done (and failed to do).

• You can use openSSL to generate your own SSL certificate (offline if you want), and send just the [effective] public key to the CA for signing.  In this way, the private part of your certificate can be protected in exactly the same way as we do GPG.
• The certificate provider/signer will verify your identity before they sign any certificate claiming "Joe's Fish Shop" is the provider of this software.
• A single compromised CA cert could be used to impersonate just about anything.  Your system trusts any number of probably 100 certificate roots, and a signature from any one of them pretty much gives the green light, unless you are manually inspecting the certificate chain and know that certain certs are lower security and/or compromised.  It's the job of the OS and the browsers to track which CAs are still trustworthy and help update your CA lists to make sure that any compromised providers are no longer trusted.
• The MS/authenticode system is not good for verifying specific certificates.  Ideally, for high-security apps, the publisher would publish their public cert and everyone would verify that the signatures from that cert, though it's a bit of work to do this.  Instead, they just check whether there's any valid certificate chain and shows you "Yes/No" that the signature is valid.
• For this reason, I don't care much for Authenticode-signed certs.  They avoid the unsightly "Unknown Publisher" when you go to run the installer, but that can be a false sense of security.
• I stand by the notion that the GPG signatures are the most secure.  Our offline GPG fingerprint is everywhere, and it's simple to check via command-line.  It's also easy to integrate into our release scripts.
  

Here's what Armory has done to this point:

• I have a Class 2 object code signing certificate, signed by StartCom.  Though at this point it might be expired.  However, it is in my name ("Alan Reiner")
• Getting a cert associated with the company requires quite a bit of ID verification work, including supplying tax returns.  We haven't been keen to do this, though I suspect we will at some point.  This would be needed for it to show "Armory Technologies, Inc." on the "Verified Publisher:" line.
• Before version 0.90, Armory used my personally-verified cert.  I generated it on an offline windows machine, and integrated an three extra steps into my release process to make sure the windows installers made it to that machine for authenticode signing before going to the offline Linux box for GPG signing.  This is quite a pain ... you can't sign afterwords or else the GPG hashes/sigs break.
• There is technically a way to do this in linux, but it didn't work with the type of .exe I was signing.  I was left with no choice but to use a dedicated offline Windows box

.

• Before version 0.90, I did go through with all this.  You should be able to run the 0.88 installers and see my name as the verified publisher
• Since version 0.90, we have been using NSIS to package up our installers.  The signing process that I previously used no longer works.  I believe it has to do with the chained installer architecture:  the outer shell of the installer is signed, but it's only purpose is to unpack the real installer and run it... which is not (easily) signed.  This means that if you take the .exe posted on the website (if it were signed this way), you could view its properties in Windows and see the signature is there.  But when you run it, you still see "Unknown Publisher."

With all this in mind, I hope you'll forgive me that I wasn't excited about going through a lot of work, to provide what I felt was less security than the GPG sig, and complicates the heck out of my signing&release process.  Is it useless?  Not exactly.  But I'm comfortable with the idea that the user either checks the GPG sig and knows it's good, or they don't and know it's not verified. 

However, it is possible that the new installer format works with linux authenticode tools, so that it could be easily integrated into the release process.  If anyone wants to try that out for us and provide a recipe for doing it, I will take a shot at it.  But I'm not anxious to put a lot effort into what is already a complex and inconvenient process (low convenience but high security!).

We can get consensus among each other

I use the hash-values too, but the values are only published for the installer not for the installed files.