To answer your question, OP, nobody really knows. It's basically a one-man operation at this point.
I certainly wouldn't go rushing into downloading any new versions of Armory.
When I brought up the same topic in another thread, I eventually got a response from Mr. Goatpig himself:
https://bitcointalk.org/index.php?topic=1494369.msg15056227#msg15056227All I can suggest it, when goatpig puts out his tip cup and says "pls" don't be surprised if he doesn't get the money he desires, says "fuck this shit" and releases a malicious Armory in the future
Good luck.
I'm not sure where you come from or why you think you have a leg to stand on in this matter.
If you've run Armory 0.92 or later, you have run my code. I've contributed over 2/3rd of the public code changes since 0.92.
0.93 is essentially my solo work, the other 5 devs were busy with closed source enterprise code. I was the defacto open source maintainer for over a year before ATI shut down development. If you had participated to the 0.93 and 0.94 testing phases you would have known that.
As for this question. Again, this is an open source project, (now 100%) community managed, so your best alternative is to read the code and build it yourself, or at least find a member of the community you trust that does that for you.
For what it's worth, I have yet to submit a commit that touches crypto or wallets in a significant way. You can verify this by checking the commit history on PyBtcWallet.py, PyBtcAddress.py, MultisigUtils.py and Transaction.py in the armoryengine folder (
https://github.com/goatpig/BitcoinArmory/tree/master/armoryengine)
The EncryptionUtils.h/cpp files and the entire cryptopp folder are untouched as well. You could hash these and verify them against the code in 0.93 if you don't like to go through commits.
As for the new wallets, I'll keep them in separate code files and let both the old and the new format coexist in Armory for quite a while. I have no need to force users onto the wallet format I'll write for BIP32/44 support, nor do I want to blur the change history in the code base.
While it's fairly easy to verify by yourself that I haven't touched any of the crypto sensitive code in 0.94 and upcoming 0.95 (most of the changes are performance and paradigm changes around the DB, the blockchain parser code), you should review or get someone to review 0.96, which will introduce the new wallet format.
This version will have significant amount of new code dealing with crypto. However it will coexist for a while with the untouched 0.93 wallet format, so you can choose to ignore those for a while as long as you don't create a wallet with the new format (I don't intent to remove any of the old format functionality for a while, rather slowly deprecate them).
I'm looking forward to this feature; Bitcoin broke new ground with using deterministic builds, and so it's only right that Armory would take up the mantle similarly. I build Armory from the source code myself also, and so don't really need the feature as such (although I'd be happy to contribute my own signatures to help confirm the veracity of official builds to the wider userbase). Another approach might be to try to get Gentoo or ArchLinux interested in packaging Armory for use with their automated client-side compilation, but likely too niche as OS's to cater to if it involved alot of work. Getting Armory into sw repos in general should be an aim IMO, but that's another conversation.
My preferred route is to split Armory into a set of stand alone libraries. I will start with the crypto code, i.e. isolate cryptopp and EncryptionUtils.h/cpp in its own repo, move to cmake for makefiles/msvs projects and dynamically link to it.
Since that will be all C++ with no need for C++11 support, it will be the first candidate for deterministic build. The new wallet code will be delivered that way too, in its own repo with its own fresh code files and dynamically linking to the crypto lib.
With deterministically built shared libraries, I'm thinking of signing the hash and hardcoding both hash and sig into the code base (i.e. have binaries hash and check the sig for the shared libs before loading them), but that's an egg and chicken problem with the crypto lib (you need the crypto methods to hash and check sigs) so I'm still wondering if that's possible/desirable.
