Author

Topic: Armory - Discussion Thread - page 171. (Read 521829 times)

newbie
Activity: 40
Merit: 0
September 07, 2012, 03:01:57 PM
Many times you can disable all that stuff in the BIOS and don't need a special kernel.  If the devices are disabled at the hardware level, it doesn't really matter if the modules are there or not Smiley

I think he's running this off a USB drive and wants to be able to boot untrusted computers (which may have network connectivity).

yes, that is my intent  Wink

USB Stick has a small FAT partition for exchanging the transactions and exporting the watching only wallets,
 a boot partition and LVM on a Luks encrypted partition for the OS

I want to be able to boot it on any computer or even a VM and be sure to cut any links to the evil world  Grin
hero member
Activity: 496
Merit: 500
September 07, 2012, 02:53:55 PM
Many times you can disable all that stuff in the BIOS and don't need a special kernel.  If the devices are disabled at the hardware level, it doesn't really matter if the modules are there or not Smiley

I think he's running this off a USB drive and wants to be able to boot untrusted computers (which may have network connectivity).
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
September 07, 2012, 02:36:51 PM
I am trying to build Armory from source (linux openSUSE 12.2, 32bit) and have a problem making Swig - it requires a static libpython which I do not have on my system ... libpython.2.7.so exists, but no static library ... is it possible to link dynamically ?

It is, and people do it.  I keep forgetting to go into the Makefile and try to figure out how to auto-detect this situation to avoid these problems.

For now, I believe you can just change any libpython2.X.a to libpython2.X.so in the Makefile.  I think that's what other non-Ubuntu compilers have been doing.

And before you ask why I'm static compiling:  it's because the compiled swig module depends on the version of python being used at runtime.  If I compile the .deb packages to distribute to users with dynamic python linking, then it only works for users that have the same version of python on their system.  This caused endless problems in the past.  However, for compiling it for yourself, it doesn't matter. 

wow that was simple  Grin  I changed the assignment of STATICPYTHON to .so and now Armory runs offline on a bootable USB stick that has never seen a network - and I created my first wallet !

next step will be recompiling the kernel to get rid of all network and bluetooth modules to be safe when booting on a machine with a network connection ....

many thanks for the help  Smiley

Many times you can disable all that stuff in the BIOS and don't need a special kernel.  If the devices are disabled at the hardware level, it doesn't really matter if the modules are there or not Smiley

Glad it worked for you!  I'll see if I can tie that into a Makefile update somehow.
newbie
Activity: 40
Merit: 0
September 07, 2012, 01:55:46 PM
I am trying to build Armory from source (linux openSUSE 12.2, 32bit) and have a problem making Swig - it requires a static libpython which I do not have on my system ... libpython.2.7.so exists, but no static library ... is it possible to link dynamically ?

It is, and people do it.  I keep forgetting to go into the Makefile and try to figure out how to auto-detect this situation to avoid these problems.

For now, I believe you can just change any libpython2.X.a to libpython2.X.so in the Makefile.  I think that's what other non-Ubuntu compilers have been doing.

And before you ask why I'm static compiling:  it's because the compiled swig module depends on the version of python being used at runtime.  If I compile the .deb packages to distribute to users with dynamic python linking, then it only works for users that have the same version of python on their system.  This caused endless problems in the past.  However, for compiling it for yourself, it doesn't matter. 

wow that was simple  Grin  I changed the assignment of STATICPYTHON to .so and now Armory runs offline on a bootable USB stick that has never seen a network - and I created my first wallet !

next step will be recompiling the kernel to get rid of all network and bluetooth modules to be safe when booting on a machine with a network connection ....

many thanks for the help  Smiley
sr. member
Activity: 350
Merit: 251
Dolphie Selfie
September 07, 2012, 01:52:45 PM
(2) The 64-bit version is not a testing version.  It's part of the official release.  In the past, Armory didn't work on 32-bit OS except for offline mode, so I always compiled two different versions.  Only recently did I realize that the 32-bit version (which now works online, too) works on 64-bit Windows, so why bother compiling them separately anymore?  I was asking users to help me test the 32-bit version in 64-bit Windows to make sure that there was no surprises.  In the near term, though, I will continue compiling both for official releases, until I am sure that there is no issues running the 32-bit version on 64-bit OS.

Ah, I see. Sorry, I totally misunderstood your last posts about this topic. As I installed the 32 bit version now, I will continue to use it (on 64 Bit Windows). If some issues occur I will report.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
September 07, 2012, 01:18:25 PM
I am trying to build Armory from source (linux openSUSE 12.2, 32bit) and have a problem making Swig - it requires a static libpython which I do not have on my system ... libpython.2.7.so exists, but no static library ... is it possible to link dynamically ?

It is, and people do it.  I keep forgetting to go into the Makefile and try to figure out how to auto-detect this situation to avoid these problems.

For now, I believe you can just change any libpython2.X.a to libpython2.X.so in the Makefile.  I think that's what other non-Ubuntu compilers have been doing.

And before you ask why I'm static compiling:  it's because the compiled swig module depends on the version of python being used at runtime.  If I compile the .deb packages to distribute to users with dynamic python linking, then it only works for users that have the same version of python on their system.  This caused endless problems in the past.  However, for compiling it for yourself, it doesn't matter. 
newbie
Activity: 40
Merit: 0
September 07, 2012, 01:01:10 PM
I am trying to build Armory from source (linux openSUSE 12.2, 32bit) and have a problem making Swig - it requires a static libpython which I do not have on my system ... libpython.2.7.so exists, but no static library ... is it possible to link dynamically ?

legendary
Activity: 1428
Merit: 1093
Core Armory Developer
September 07, 2012, 11:54:22 AM
Two things:

  • It would be nice to let the user choose the install location in the windows installer. (This is how it's mostly done in Windows. There are no hard default file locations like in most linux-distros.)
  • If the 64-bit version for Windows is only for testing, it would be nice to tag it accordingly at the donwload page (http://bitcoinarmory.com/index.php/get-armory)

(1) Of course it's possible to do this, but I never figured it out using the MSI-creator program I'm using (War Setup).  It can't be hard, I just have to dig through the options.  I'll add that to my list of things to look into next time I'm waiting for something to compile.

(2) The 64-bit version is not a testing version.  It's part of the official release.  In the past, Armory didn't work on 32-bit OS except for offline mode, so I always compiled two different versions.  Only recently did I realize that the 32-bit version (which now works online, too) works on 64-bit Windows, so why bother compiling them separately anymore?  I was asking users to help me test the 32-bit version in 64-bit Windows to make sure that there was no surprises.  In the near term, though, I will continue compiling both for official releases, until I am sure that there is no issues running the 32-bit version on 64-bit OS.
hero member
Activity: 496
Merit: 500
September 07, 2012, 11:43:07 AM
However, my understanding is that supply is limited, so it may be many weeks before new customers can get their hands on one...

Newark seems to have at least 100 to ship today. I just purchased one, we'll see how it goes...

I also purchased on on BitMit, but that's from Germany and who knows when it will ship... Want to have my bases covered. Smiley
sr. member
Activity: 350
Merit: 251
Dolphie Selfie
September 07, 2012, 11:38:11 AM
Two things:

  • It would be nice to let the user choose the install location in the windows installer. (This is how it's mostly done in Windows. There are no hard default file locations like in most linux-distros.)
  • If the 64-bit version for Windows is only for testing, it would be nice to tag it accordingly at the donwload page (http://bitcoinarmory.com/index.php/get-armory)
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
September 05, 2012, 10:35:16 PM
I got Armory running on the Raspberry Pi. This might be really useful for inexpensive, secure offline wallets.

...


Fantastic!  This is one step up for those users who want offline wallets, but can't find an old laptop, or don't want to deal with an old laptop ... $35 for a RaspberryPi is pretty awesome.  Plus, it might be fun to mess around with it (for some of us Smiley).  However, my understanding is that supply is limited, so it may be many weeks before new customers can get their hands on one...

On a slightly-related note, I just got a request about improving USB security on offline linux machines.  I don't know what window manager is used by default on the RPi, but I bet the process is similar.  I posted a starter discussion about it in the "Improving offline wallets" thread.  Any extra recommendations are welcome!

Also:  thanks for the patch and instructions, Filo!  It looks like it will be fairly easy to integrate most of the updates directly into the project.
newbie
Activity: 11
Merit: 0
September 05, 2012, 06:32:55 PM
I got Armory running on the Raspberry Pi. This might be really useful for inexpensive, secure offline wallets.

https://i.imgur.com/IaAHAl.jpg


All the instructions/files here
https://gist.github.com/3646033
legendary
Activity: 1358
Merit: 1002
September 04, 2012, 01:51:07 PM
Startssl.com may be what you're looking for. You can sign code with their level 2 certs which cost $60 for unlimited certs for 2 years.
https://www.startssl.com/?app=2
https://www.startssl.com/?app=25#60
https://forum.startcom.org/viewtopic.php?f=15&t=1654
hero member
Activity: 560
Merit: 500
I am the one who knocks
September 04, 2012, 01:21:11 PM
I wonder if I can generate my own certificate, offline, and send them the public key to sign...?  Do you know if they always generate the full key for you?  I'd prefer that no one else has the private key, but maybe that's a level of service I can't expect at the <$200/yr level.
I believe that code signing certificates are no different technically from SSL certs, other than a special bit that says it is a code signing cert.

In others words: I see no reason why the CSR would be any different.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
September 04, 2012, 12:35:38 PM
NOTE: if someone knows how to "build-in" a GPG signature into a Windows installer (*.msi file), that would be great.
You can't build-in a GPG signature into anything since they always sign the whole object. The political disconnect between GPG and the commercial software vendors is too high. You need to spend money on a code signing certificate. Since you aren't signing a kernel-level driver you can go for the cheapest ones.

Here's the link to some random blog that has a sensible discussion, links and prices in the comments:

http://www.wintellect.com/cs/blogs/jrobbins/archive/2007/12/21/code-signing-it-s-cheaper-and-easier-than-you-thought.aspx

Ahh, perfect.  I should've known that GPG keys were not "accepted" in the MS world.

The blog article you linked is old, but it is good discussion.  There's definitely no more $80/yr special, it looks like $180/yr to get a signing certificate.  It's probably worth swallowing my pride, and paying into the system and move on with life.  After all, I did receive a lot of donations, I guess this is an appropriate thing to spend that on Smiley

I wonder if I can generate my own certificate, offline, and send them the public key to sign...?  Do you know if they always generate the full key for you?  I'd prefer that no one else has the private key, but maybe that's a level of service I can't expect at the <$200/yr level.
legendary
Activity: 2128
Merit: 1073
September 04, 2012, 10:33:07 AM
NOTE: if someone knows how to "build-in" a GPG signature into a Windows installer (*.msi file), that would be great.
You can't build-in a GPG signature into anything since they always sign the whole object. The political disconnect between GPG and the commercial software vendors is too high. You need to spend money on a code signing certificate. Since you aren't signing a kernel-level driver you can go for the cheapest ones.

Here's the link to some random blog that has a sensible discussion, links and prices in the comments:

http://www.wintellect.com/cs/blogs/jrobbins/archive/2007/12/21/code-signing-it-s-cheaper-and-easier-than-you-thought.aspx
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
September 03, 2012, 08:30:48 PM
Someone just asked me how to verify the digital signatures on the above packages.  

I don't know how to do this in Windows without installing bloat-y software.  But it's built-in, in Linux, and it's quite easy.  And once you have the Armory public key downloaded and imported to your offline computer, it's one command to verify the signatures.  

NOTE: if someone knows how to "build-in" a GPG signature into a Windows installer (*.msi file), that would be great.  For now, I'm just signing the hash of the .msi file.



Use linux to verify the authenticity of the Armory installers you download

  • (1) Download the Armory Signing Public Key.  It can also be retrieved via a public key server.  Just search for "Armory" and you will find it.
  • (2) Download the installers you want to verify (links at the bottom of this post).  You only need the md5.asc file (signed MD5 hashes) if you want to verify the Windows installer
  • (3) Put all the downloaded files onto a USB and take to your offline linux computer (skip this step if you're already in Linux!)
  • (4) Go to Applications-->Accessories-->"Passwords and Encryption Keys".  Go to File-->Import....  Select the Alan_C_Reiner_ArmorySigningPublic.asc
  • (5) VERIFY THE KEY ID: Once the key is imported, click the "Other Keys" tab.  You should see:  Alan C. Reiner [email protected] 'Armory Signing Key' | 98832223 .   Do not continue if it does have 98832223! (backwards, that is 32223889)

Now the key is imported and you can skip the previous steps on future releases.  Here's how to verify the *.deb files:

(1) Open a terminal, and navigate to the USB key where the installers are located (probably /media/usbkey or something like that)
(2) To verify the *.deb files, type "dpkg-sig --verify *.deb".  You should see something like this:
Quote
/media/usbkey$ dpkg-sig --verify *.deb
Processing armory_0.82.4-1_amd64.deb...
GOODSIG _gpgbuilder 821F122936BDD565366AC36A4AB16AEA98832223 1346525528
Processing armory_0.82.4-1_i386.deb...
GOODSIG _gpgbuilder 821F122936BDD565366AC36A4AB16AEA98832223 1346525533


The "GOODSIG" is all you need!  To verify the windows MD5 hash file, you use regular GPG:

Quote
/media/usbkey$ gpg --verify version_0.82.4.md5.asc
gpg: Signature made Sat 01 Sep 2012 02:55:33 PM EDT using RSA key ID 98832223
gpg: Good signature from "Alan C. Reiner (Armory Signing Key) <[email protected]>"
Primary key fingerprint: 821F 1229 36BD D565 366A  C36A 4AB1 6AEA 9883 2223


The MD5 file is now confirmed to be legitimate.  The last thing is to make sure the .msi file has the same hash as is listed in the .md5.asc we just verified:

Quote
/media/usbkey$ md5sum *.msi
e3fa56fee145986bace4f51199778005  armory_0.82.4-alpha_win32_and_win64.msi


If you open the md5.asc file, you will see the hashes for each of the files:

Quote

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

213c76e709c5cb6e80980a6f7bd4dca0  armory_0.82.4-1_amd64.deb
9602fd85514b247d55bc6c19f076860f  armory_0.82.4-1_i386.deb
e3fa56fee145986bace4f51199778005  armory_0.82.4-alpha_win32_and_win64.msi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBAgAGBQJQQlolAAoJEEqxauqYgyIjsFEP/36qGu0/ZbBFt8nQc3XBVDnp
...
-----END PGP SIGNATURE-----



Here's the download links:
http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.82.4-alpha_win32_and_win64.msi
http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.82.4-1_amd64.deb
http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.82.4-1_i386.deb
Signed MD5 hashes (mainly for Windows; the *.deb files have the signatures built-in)
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
September 03, 2012, 10:14:44 AM
I finally got 64-bit Windows VM back up.  I can now compile 64-bit apps again.  However, I'd like to keep all Windows users using 32-bit, if it doesn't cause problems...

Windows users:  please use the 32-bit version unless you have problems with it.  If you experience an issue with the 32-bit version on 64-bit windows, please install the 64-bit version only to check whether the problem goes away.  If the problem goes away, please report it here, and I will go back to making separate versions for 32- and 64-bit windows.

http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.82.4-alpha_win64.msi

legendary
Activity: 1428
Merit: 1093
Core Armory Developer
September 02, 2012, 10:52:29 AM
Is there a config option or cmd-line option to "not show splash screen"?

It annoys the hell out of me because it covers my stuff and can neither be moved nor closed (using weird window manager).

No there is not, but fear not, the next major release (with multi-threading) will do away with the splash screen completely!  I'm just finishing butchering the code base to get the multi-threading code implemented.  There will be lots of testing, but hopefully only another week or two before it's done.  

awesome! btw: last git pull I did (after about 6 weeks of abstinence) was the first one that didn't get me into any kind of trouble regarding being able to run Armory. Before I had all kinds of issues after updates about 2 or 3 times. Thanks for making things more smooth over time.

Fwhew!  Please don't hesitate to tell me if things are working, since I usually only hear when things are not working, and get stressed out that Armory is falling apart!  So, thanks Molec!
donator
Activity: 2772
Merit: 1019
September 02, 2012, 04:42:49 AM
Is there a config option or cmd-line option to "not show splash screen"?

It annoys the hell out of me because it covers my stuff and can neither be moved nor closed (using weird window manager).

No there is not, but fear not, the next major release (with multi-threading) will do away with the splash screen completely!  I'm just finishing butchering the code base to get the multi-threading code implemented.  There will be lots of testing, but hopefully only another week or two before it's done. 

awesome! btw: last git pull I did (after about 6 weeks of abstinence) was the first one that didn't get me into any kind of trouble regarding being able to run Armory. Before I had all kinds of issues after updates about 2 or 3 times. Thanks for making things more smooth over time.
Jump to: