It breaks shortcuts or any use case where someone is trying to run Armory from somewhere other than the Armory source tree. So if they are above a level and try to run "python BitcoinArmory/ArmoryQt.py" that should fail too.

A solution is to modify self.dbExecutable in SDM.py to be prepended by the following path.

Armory is trying to open ArmoryDB as a relative path. That only works if you are have used cd to enter the Armory source tree first. The solution is for Armory to use absolute paths, so people don't need to be in the same directory as Armory to run it.

Here's the repo for the Namecoin fork of Armory: https://github.com/namecoin/BitcoinArmory. If you are checking out the commit history, make sure you look as far back as this commit: https://github.com/namecoin/BitcoinArmory/commit/90351e11601cc5e2c09481dad6b56f6a7a4f620e.

As you can see it hasn't been updated since late 2014. For now, it is abandoned. You can see some reasoning in the remaining open issue. That issue also links to this thread of which you are also the original poster, so you are probably already aware of that thread.

The necessary changes were already covered well by knightdk. For Namecoin, we still needed to touch the C++ code even though Namecoin uses the same hash algorithm as Bitcoin, because we needed to use a different directory to load blocks from (~/.bitcoin versus ~/.namecoin on Linux) and because Namecoin uses merged mining, so the block parsing needs to account for that. For Litecoin you definitely need to touch the C++ code to use scrypt as the hashing algorithm (as knightdk already stated).

If you don't know where to start, the Namecoin fork is better to use as a reference than nothing, even though it is outdated.

The postrm is located in dpkgfiles (https://github.com/goatpig/BitcoinArmory/blob/master/dpkgfiles/postrm in the master branch for example). And it does look like there are xdg-utils uninstall commands in that script. So that seems like it is the source of the error when installing a new version over the old version of Armory.

The Python code you added looks correct to me. The problem is that the temporary directory gets recreated from dpkgfiles each time you run make_deb_package.py. So if you are copying to or modifying the file in the temporary directory instead of dpkgfiles, it will get overwritten when you run make_deb_package.py. So if you aren't doing it already, you should modify the postinst in dpkgfiles and then try running make_deb_package.py.

Maybe the other packages that don't fail to install the desktop file use an install file (debian/armory.install in Armory's case) to install the desktop files? See http://packaging.ubuntu.com/html/debian-dir-overview.html and search the page for "desktop" to find what I am talking about.

You won't be able to generate the desktop files on demand like the postinst script currently does, but it looks like there are static desktop files in dpkgfiles currently anyway.

Carlton, does /usr/share/desktop-directories/ exist? If not, what happens if you make that directory and try to retrigger the xdg-desktop-menu calls?

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.

First off, I'm just speaking for myself here.

This is a great question. Indeed, there is currently no way to verify that the Ubuntu binaries came from the source code.

Lets start with a description of the way that Debian/Ubuntu packaging works. With Debian, the package maintainer creates one of the packages (the one for the architecture that the maintainer is building on) and the Debian infrastructure builds the rest of the packages for the other architectures. I'm not as familiar with Ubuntu, but I think Ubuntu builds all the packages on their infrastructure (though I may just be thinking of the way PPAs work).

There is a reproducible build effort underway to make Debian as a whole reproducible. You can check out the progress. The percentage of packages that are reproducible is a little above 80% as of the writing of this post. In the future, it looks like it will be a requirement that uploaded packages be reproducible, otherwise they won't be accepted into the Debian Archive. But right now there is no requirement that a package be reproducible.

How does Debian's effort affect Ubuntu? In 2013, Colin Watson stated that Ubuntu will inherit the changes over the natural merging and syncing of packages from Debian. I don't know how many packages are reproducible in Ubuntu, because it doesn't seem like Ubuntu has the infrastructure setup to rebuild and compare packages for reproducibility like Debian has.

Now I probably should have put this earlier, because a lot of you are probably wondering what reproducible builds are and how do they affect the verification that binaries came from the source code. Reproducible builds involve multiple people building the binaries from a particular version of the source code. The hashes of the binaries should match those of all the people building the binaries. If there is a discrepancy in the hashes, then it means that there was some difference in the resulting binaries (whether that means someone's computer was compromised or there was something non-deterministic about the build process that introduced differences). The reproducible build process means that every single builder needs to be compromised to compromise the resulting binaries. If the current method that Debian uses of building packages is used instead, then there is a single target (either the maintainer of the package or the Debian build infrastructure) to compromise. There are some things that reproducible builds just don't protect against. If everyone is using the same OS to do the builds, then it is possible to just compromise the OS and influence the build that way. But you have to define the threat you are trying to protect against and focus on that. Even if you have a foolproof way of making sure your software stack is secure, there is still the hardware you are running. Do you know for sure that your hardware isn't compromised? Of course that worry can be mitigated by having the builders using a variety of hardware, so that it is less likely that all the hardware is compromised.

That explains the Debian/Ubuntu reproducible build effort. However, there is also Gitian, which was originally developed for Bitcoin Core, but is also used by Tor Browser Bundle. Armory is also using Gitian along with the Debian reproducible build toolchain to make Armory reproducible, but that isn't finished yet (I'm pleasantly surprised how many people have asked questions related to reproducible builds after the Armory effort was started). With Gitian, the build is performed in a VM and there is this assert file produced that contains the hashes of the resulting binaries (among other data). The assert file is signed by the builder. In Bitcoin Core's case the assert file and signature get added to a repo called Gitian.sigs on GitHub. Then users can download the signatures and verify them. You should verify the signatures of people you trust.

I think this is a pretty comprehensive answer, but let us know if there is something I should go into more detail on. Unfortunately the reproducible build efforts for OSes aren't complete yet, so you still have to trust in the build processes used and the people that do the builds.

I can prove that doug_armory works for Armory, but I can't prove that I do. If you look at the last person before the advisors on the about page on the Armory website, you will see Doug's name and near it is the text doug_armory with a link to his bitcointalk profile.

I'm interning under Doug's supervision. It appears that I am not listed on the about page, so I can't use that to prove I work for Armory. Maybe Doug or someone can state that I work for Armory, but you still might not trust them just because they themselves work for Armory. On GitHub, under the pull requests section, you will find a lot of closed pull requests from me, meaning that the code was merged into Armory, but that doesn't necessarily mean that I work for Armory, because some open source projects accept contributions from outside contributors. And still, there is nothing linking the GitHub account josephbisch to this bitcointalk account josephbisch.

We are working on reproducible builds for Armory. The goals are Linux deb packages and a Raspberry Pi package for the next version of Armory (0.94). Right now the only way to be 100% certain that the binaries came from the source code is to build Armory from source yourself. After the reproducible builds exist, you will be able to verify the signatures of people you trust to be sure that the binaries came from the source code without needing to build Armory yourself. You will also be able to follow the reproducible build process to make your own build and sign off on it, so that people that trust you can verify your signature.

The Raspberry Pi package uses Gitian, but the Linux deb packages will use a script that uses the Debian Reproducible Toolchain. We will have instructions for reproducible builds using both systems. The Debian Reproducible Toolchain produces a buildinfo file instead of an assert file, but the idea is more or less the same.

It looks like 0.94 will just be using the signatures to verify that multiple people were able to get the same hash of the binaries. Only if a certain number of signatures are correct will the usual signing process continue. There will probably be a separate repository for signatures, like the Bitcoin gitian.sigs repo, so that ambitious users can verify the signatures themselves.

It seems like the ultimate goal is to have the Secure Downloader (that is part of Armory) verifying the signatures of multiple ATI employees, so that there is not a single computer doing the build and a single key signing the builds. But that won't happen for 0.94.

Work is also being done for OS X and Windows using Gitian. But those definitely won't be a part of 0.94.

Let me know if you have any more you want to know about this. Hopefully we will have 0.94 testing releases soon and then people will be able to try out the reproducible build process.

The gitian-builder tools only support KVM, LXC, and maybe VirtualBox (apparently make-base-vm can't actually make VirtualBox VMs). I think Xen support is something that devrandom (https://github.com/devrandom) would know more about.

As for the Ubuntu choice, the gitian-builder tools only support Ubuntu VMs (at least right now). I don't think there is anything preventing Debian VM support other than the fact that no one seems to have tried it. But that would be something that has to be changed with gitian-builder (https://github.com/devrandom/gitian-builder) rather than Armory. I'm not sure what ATI would want to go with if there was a choice between Debian and Ubuntu.

Hi, Doug (doug_armory) and I are the people working on Gitian builds.

There are two OSes: the base OS and the build OS that runs in a VM. The base OS hosts the build OS VM and the build OS VM is where the actual building of Armory takes place.

It is important that the OS of the VM be consistent so that everyone gets the same results from the build. In Armory's case that is Ubuntu 14.04. The OS of the VM is specified in the descriptor under suites.

So when you create the VM for Armory, you want to run something like:

It should be possible for the base OS to be any OS that has the prerequisite programs for gitian-builder. I personally use Debian Jessie. The only prerequisite not available from Debian is python-vm-builder, so I downloaded the .tar.gz from Ubuntu and installed it.

Click on "Previous Stable" at https://bitcoinarmory.com/download/.

Wow, this thread is a blast from the past!

It looks like the IETF spec currently has ACH, Bitcoin, and testnet Bitcoin. But it is general, so that Namecoin could be added in the future.

To import armoryengine.ALL, you need:

armoryengine directory and its contents
bitcoinrpc_jsonrpc directory and its contents
CppBlockUtils.py
_CppBlockUtils.so
qrcodenative.py
SDM.py

With just those files and directories, I was able to run the samples at https://bitcoinarmory.com/using-armory-python/.

The issue is that the Armory binary is expecting version 4.7 or above, but Ubuntu 12.04 only has 4.6.3. It does appear to be a mistake since they do list 12.04+ as being supported. Hopefully they'll see this and fix it. Even better would probably be for you to file a ticket at support.bitcoinarmory.com so they will definitely be aware of this issue.

I see there is some work towards Python 3 support that has been started on some branches on GitHub. Is there an ETA or expected version number for Python 3 support?

If you are running Debian Jessie on the pi, you might be able to run the binaries from Debian Sid https://packages.debian.org/unstable/main/armory). Just note that the Debian binaries are meant to be updated through your package manager, so it has the built-in update functionality disabled.

I haven't actually tested this with a pi.

You don't have to worry about the server being compromised, because the software would be signed. The problem is that the person building the software would need to be trusted to not put an exploit into the binaries that the person builds. Someone could probably set up a repository using the binary packages provided by Armory. That way they would be signed by ATI and therefore trusted.

That is a good idea though.