Pages:
Author

Topic: Moving bitcoin.org to a hardened server? (Read 2083 times)

vip
Activity: 1386
Merit: 1136
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
October 12, 2012, 09:22:43 AM
#22
There is an entire field of computer science research about repeatable, trusted software builds. Due to address randomization and other 'anti-vulnerability' hacks in compilers, even building the same binary on the same system can be a challenge.

I always thought address randomization was done by the OS at runtime so that the layout would be different per instance of the executable.  If the "randomness" had to be compiled into the executable, there would need to be a unique executable for each user to have any value, which would make production of installation media and downloads and signed binaries a challenge.


http://xkcd.com/221/
member
Activity: 69
Merit: 10
October 10, 2012, 05:03:53 PM
#21
Compiling is a different matter, everything must be exactly the same or you'll end up with differences.  My box has slightly different libraries, and a very different compiler version, so the bitcoind that I build for my own use is wildly different from the official releases, for example.

They actually use a virtual machine to create a predictable build environment for the public releases.  If you hang out in #bitcoin-dev around release day, you'll see that even with all the work they put into the VM, they have differences fairly often and need to resolve them.

There is an entire field of computer science research about repeatable, trusted software builds. Due to address randomization and other 'anti-vulnerability' hacks in compilers, even building the same binary on the same system can be a challenge.
jr. member
Activity: 56
Merit: 1
October 10, 2012, 02:30:58 PM
#20
The integrity questions aside, I think that publishing torrents of the releases would be useful in general.

This is especially true for the block chain download.

Yes, torrents would be useful -- and some infrastructure is coming down the pipe for this.

Upcoming version 0.7.1, released hopefully this week or early next week, will automatically import any 'bootstrap.dat' files that is found in the bitcoin data directory.

This feature is intended to enable a bootstrap torrent to be downloaded.  Simply drop the torrent's data file (bootstrap.dat) into your directory, and bitcoin will do the rest.

The next step is for some volunteers to generate the torrent, and other volunteers to "beta test" the torrent by downloading it, and making sure it imports correctly into bitcoin.

The nice thing about this process is that these volunteers may be untrusted:  bitcoin will fully verify the input data, just like it does over the network.  A malicious torrent would largely waste everybody's time, but be quickly noticed as malicious.



This will not be automatic updates, correct?
legendary
Activity: 1596
Merit: 1091
October 10, 2012, 02:28:03 PM
#19
The integrity questions aside, I think that publishing torrents of the releases would be useful in general.

This is especially true for the block chain download.

Yes, torrents would be useful -- and some infrastructure is coming down the pipe for this.

Upcoming version 0.7.1, released hopefully this week or early next week, will automatically import 'bootstrap.dat', if that file exists in the bitcoin data directory.

This feature is intended to enable a bootstrap torrent to be downloaded.  Simply drop the torrent's data file (bootstrap.dat) into your directory, and bitcoin will do the rest.

The next step is for some volunteers to generate the torrent, and other volunteers to "beta test" the torrent by downloading it, and making sure it imports correctly into bitcoin.

The nice thing about this process is that these volunteers may be untrusted:  bitcoin will fully verify the input data, just like it does over the network.  A malicious torrent would largely waste everybody's time, but be quickly noticed as malicious.

hero member
Activity: 868
Merit: 1000
October 10, 2012, 01:59:54 PM
#18
Also, through gitian, everyone can build the binaries and verify they match byte-for-byte the distributed ones, and their hash matches the signed checksums. We do not publish binaries before a few developers have succesfully built the exact same binary.

The process is somewhat contrived, but it allows for very deep inspection of what is distributed.

How can binaries build on my machine would match binaries build on other machine byte-by-byte?

What do you expect might differ per machine?  If you print the same MS Word doc from two machines it should look the same. The same idea applies to compiling the same source code.

Compiling is a different matter, everything must be exactly the same or you'll end up with differences.  My box has slightly different libraries, and a very different compiler version, so the bitcoind that I build for my own use is wildly different from the official releases, for example.

They actually use a virtual machine to create a predictable build environment for the public releases.  If you hang out in #bitcoin-dev around release day, you'll see that even with all the work they put into the VM, they have differences fairly often and need to resolve them.

Can't they just make a vm-image that all of them can use? That should sort it out ? At least, then they would have the same environment.
kjj
legendary
Activity: 1302
Merit: 1025
October 10, 2012, 11:39:15 AM
#17
Also, through gitian, everyone can build the binaries and verify they match byte-for-byte the distributed ones, and their hash matches the signed checksums. We do not publish binaries before a few developers have succesfully built the exact same binary.

The process is somewhat contrived, but it allows for very deep inspection of what is distributed.

How can binaries build on my machine would match binaries build on other machine byte-by-byte?

What do you expect might differ per machine?  If you print the same MS Word doc from two machines it should look the same. The same idea applies to compiling the same source code.

Compiling is a different matter, everything must be exactly the same or you'll end up with differences.  My box has slightly different libraries, and a very different compiler version, so the bitcoind that I build for my own use is wildly different from the official releases, for example.

They actually use a virtual machine to create a predictable build environment for the public releases.  If you hang out in #bitcoin-dev around release day, you'll see that even with all the work they put into the VM, they have differences fairly often and need to resolve them.
vip
Activity: 1386
Merit: 1136
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
October 10, 2012, 09:07:13 AM
#16
Also, through gitian, everyone can build the binaries and verify they match byte-for-byte the distributed ones, and their hash matches the signed checksums. We do not publish binaries before a few developers have succesfully built the exact same binary.

The process is somewhat contrived, but it allows for very deep inspection of what is distributed.

How can binaries build on my machine would match binaries build on other machine byte-by-byte?

What do you expect might differ per machine?  If you print the same MS Word doc from two machines it should look the same. The same idea applies to compiling the same source code.
legendary
Activity: 966
Merit: 1000
October 10, 2012, 01:00:18 AM
#15
The integrity questions aside, I think that publishing torrents of the releases would be useful in general.

This is especially true for the block chain download.
member
Activity: 69
Merit: 10
October 09, 2012, 09:31:09 PM
#14
In my personal opinion, bitcoin.org along with it's binaries should be hosted on a hardened server,
separate from any other service.

A hardened server is irrelevant. Trusting pgp verification is relevant. With pgp verification, and a trust path back to the signer, the binaries and pgp sig can be hosted anywhere.

Has there been a pgp keysigning party which involves key 29D9 EE6B 1FC7 30C1 (short key known as 0x1FC730C1)?
member
Activity: 69
Merit: 10
October 09, 2012, 09:16:48 PM
#13
The download links on bitcoin.org go to sourceforge.  Also, the binaries are hashed and the hashes are signed with a well known key, so anyone that bothers to check would notice.

Sourceforge mirrors have been cracked in the past, here's a recent example, https://bitcointalksearch.org/topic/sourceforge-mirror-hacked-bitcoin-could-be-next-target-113018
full member
Activity: 151
Merit: 100
October 09, 2012, 08:12:22 PM
#12
Also, through gitian, everyone can build the binaries and verify they match byte-for-byte the distributed ones, and their hash matches the signed checksums. We do not publish binaries before a few developers have succesfully built the exact same binary.

The process is somewhat contrived, but it allows for very deep inspection of what is distributed.

How can binaries build on my machine would match binaries build on other machine byte-by-byte?
legendary
Activity: 2436
Merit: 2119
1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k
October 09, 2012, 03:19:07 PM
#11
Here is one of the validation files for 0.7.0.

Any changes to any of those files will change their hashes, and changes to any of the hashes will break the signature.  If you've verified the key, you can check them for each release.  By the way, the key they are signed with (currently) can be found here.  (But please don't take my word for it, verify the key yourself before you sign it or use it.)

But how can I trust you? Or that the owners of this site haven't modified your post? Wink

Perhaps key-signing parties need to become part of the Bitcoin deal.

Probably should have these files torrented too for the decentralization. Would that decrease or increase security? Possibly neither I suspect.

Heh, you don't trust me, or my posts.  In fact, I explicitly tell you not to.

If, for some strange reason, you did want to trust me, I'd tell you that if:
1) the SHASUMS.asc file you are looking at has the SHA256 hash d2f06aca782ae7bc1f0df13e2646ea3343f09048019aa3136832c11c04a08fc7
and
2) the 1FC730C1 key you've downloaded verifies the signature in that file
then according to me (or anyone that has access to the forum database or can intercept either my post or your loading of my post), you have the right key and file.

Torrent would ensure that the file you downloaded was the file described in the torrent, but it couldn't tell you that the torrent was legit.

One thing that you can do is check the hashes and signatures on several of the releases you've used in the past, and decide that you've already trusted that key, whoever it belongs to, without knowing it, and then sign it with your own key.  That way, you'd at least know that future releases were signed by the same key as before.

I was more thinking of the torrent as a way of decentralizing availability of the app. Though the fact that it is hashed is definitely a bonus.
legendary
Activity: 1072
Merit: 1174
October 04, 2012, 03:28:09 PM
#10
Also, through gitian, everyone can build the binaries and verify they match byte-for-byte the distributed ones, and their hash matches the signed checksums. We do not publish binaries before a few developers have succesfully built the exact same binary.

The process is somewhat contrived, but it allows for very deep inspection of what is distributed.
kjj
legendary
Activity: 1302
Merit: 1025
October 04, 2012, 02:29:20 PM
#9
Here is one of the validation files for 0.7.0.

Any changes to any of those files will change their hashes, and changes to any of the hashes will break the signature.  If you've verified the key, you can check them for each release.  By the way, the key they are signed with (currently) can be found here.  (But please don't take my word for it, verify the key yourself before you sign it or use it.)

But how can I trust you? Or that the owners of this site haven't modified your post? Wink

Perhaps key-signing parties need to become part of the Bitcoin deal.

Probably should have these files torrented too for the decentralization. Would that decrease or increase security? Possibly neither I suspect.

Heh, you don't trust me, or my posts.  In fact, I explicitly tell you not to.

If, for some strange reason, you did want to trust me, I'd tell you that if:
1) the SHASUMS.asc file you are looking at has the SHA256 hash d2f06aca782ae7bc1f0df13e2646ea3343f09048019aa3136832c11c04a08fc7
and
2) the 1FC730C1 key you've downloaded verifies the signature in that file
then according to me (or anyone that has access to the forum database or can intercept either my post or your loading of my post), you have the right key and file.

Torrent would ensure that the file you downloaded was the file described in the torrent, but it couldn't tell you that the torrent was legit.

One thing that you can do is check the hashes and signatures on several of the releases you've used in the past, and decide that you've already trusted that key, whoever it belongs to, without knowing it, and then sign it with your own key.  That way, you'd at least know that future releases were signed by the same key as before.
legendary
Activity: 2436
Merit: 2119
1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k
October 04, 2012, 01:57:39 PM
#8
Here is one of the validation files for 0.7.0.

Any changes to any of those files will change their hashes, and changes to any of the hashes will break the signature.  If you've verified the key, you can check them for each release.  By the way, the key they are signed with (currently) can be found here.  (But please don't take my word for it, verify the key yourself before you sign it or use it.)

But how can I trust you? Or that the owners of this site haven't modified your post? Wink

Perhaps key-signing parties need to become part of the Bitcoin deal.

Probably should have these files torrented too for the decentralization. Would that decrease or increase security? Possibly neither I suspect.

kjj
legendary
Activity: 1302
Merit: 1025
October 04, 2012, 01:49:19 PM
#7
Here is one of the validation files for 0.7.0.

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

4d4bba64926e86c4dfe8603ef2d7c2b942c29d47  bitcoin-0.7.0-linux.tar.gz
f5e4950451fb84806a4c86709d8f9e7aecbf0512  bitcoin-0.7.0-macosx.dmg
dce46beef11f4a82c0c24ea2d2fc4b39b680143c  bitcoin-0.7.0-win32-setup.exe
851708693d0609803eb917368c28d1142e029a31  bitcoin-0.7.0-win32.zip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQIcBAEBAgAGBQJQXLxgAAoJECnZ7msfxzDBgf0P/29r98AR853nwJ6Rz0Mn5b9v
ipE4jqenAB3cOa+9BkSBQ078clO8uAunYXBRQQtnqAd2a3/PCrnJYuzlZpHYA672
v9Gs2Yr5gsDesZmgQpTIA3y75rykc6Q1JCekGIIZXDL0VwX+4Ovj3KTr4Gwa+JdI
3XZi1ooFofCtFt6/8j7inzd/V3ORckY7lIMVkYMvzEVcpXUKzR5PQBhnwSNdHrxg
KzfbSMrdgapvMIPTgy5hIMEta0fS9VFJDXXyepOAzsGwm9DtBQqi5+c/nnC1cisb
NXAzJsS0Wd1ltfBlfT5t8QAez+pfeS5p5X17+OHJoUhp7K0j/dDKt2Q8EcpZZC7O
iNTcmIGrt0ATXorvxT/Mtv9D8mZOOfDrrjx4ikFr4HmD/ALhZnu9M1iyvdPnKV8T
m3BFEQ345/HmHNtpb0GzhJQzIronBsqEkuwNfsTZd4SBuAzAvoW8qoLb+Uqr3s+0
ssNI1YJXZYOpKiarzNXsvDB/ssjLIDEKQ+aGoXf0XI9KRYUfE4RLKHWvzYBv3IQu
pQy3pClbQ4SLpv6/PKrN4dqZOpRfXYCdXgvngVCyOSiPwC6Ol6hRE0WcWvZJcVhu
D+hSuhJGnM0ipEE1kPEKGiGhp7B27GfXaXVQNTuOWMWBK6ttKf5AbZaGHo6rQ3qV
2dcVI8EmSxYaBde/HqkH
=CZgV
-----END PGP SIGNATURE-----

Any changes to any of those files will change their hashes, and changes to any of the hashes will break the signature.  If you've verified the key, you can check them for each release.  By the way, the key they are signed with (currently) can be found here.  (But please don't take my word for it, verify the key yourself before you sign it or use it.)
hero member
Activity: 868
Merit: 1000
October 04, 2012, 01:42:36 PM
#6
Thanks for that - I was wondering if there was a way to confirm authenticity of the official downloads if I wanted to be really anal retentive.

I guess how anal retentive you want to be is directly proportional to the amount of bitcoins you have.
hero member
Activity: 518
Merit: 500
Manateeeeeeees
October 04, 2012, 01:29:10 PM
#5
I just got aware of the fact that bitcoin.org is served through pages.github.com.

Code:
ping www.bitcoin.org
PING bitcoin.org (207.97.227.245) 56(84) bytes of data.
64 bytes from pages.github.com (207.97.227.245)

I haven't develved deep into the issues surrounding github.com, neither have I used it much,
but there's been some writings about compromises of github during the last months, so I was
wondering if we would not be safer off disconnecting the bitcoin.org page with it's downloadable
binaries completely from github.com.

Could a github compromise lead to binaries on bitcoin.org being compromised ? With the current
setup, it seems so.

In my personal opinion, bitcoin.org along with it's binaries should be hosted on a hardened server,
separate from any other service.

Please discuss.

The download links on bitcoin.org go to sourceforge.  Also, the binaries are hashed and the hashes are signed with a well known key, so anyone that bothers to check would notice.

Thanks for that - I was wondering if there was a way to confirm authenticity of the official downloads if I wanted to be really anal retentive.
kjj
legendary
Activity: 1302
Merit: 1025
October 04, 2012, 01:07:35 PM
#4
I just got aware of the fact that bitcoin.org is served through pages.github.com.

Code:
ping www.bitcoin.org
PING bitcoin.org (207.97.227.245) 56(84) bytes of data.
64 bytes from pages.github.com (207.97.227.245)

I haven't develved deep into the issues surrounding github.com, neither have I used it much,
but there's been some writings about compromises of github during the last months, so I was
wondering if we would not be safer off disconnecting the bitcoin.org page with it's downloadable
binaries completely from github.com.

Could a github compromise lead to binaries on bitcoin.org being compromised ? With the current
setup, it seems so.

In my personal opinion, bitcoin.org along with it's binaries should be hosted on a hardened server,
separate from any other service.

Please discuss.

The download links on bitcoin.org go to sourceforge.  Also, the binaries are hashed and the hashes are signed with a well known key, so anyone that bothers to check would notice.
hero member
Activity: 868
Merit: 1000
October 04, 2012, 10:56:44 AM
#3
You mean... people can lose money because of hosting provider? Ridiculous...
/sarcasm Smiley

Sarcasm goes well with me, however, it could also be an external attack. We seek non-centralization, no ?
Pages:
Jump to: