SourceForge mirror hacked. Bitcoin could be next target.

[runeks]

Here's a bash script that verifies the current 0.7.0 release. It returns 0 if everything matches up, and 1 if something went wrong (bad signature/bad file hash).

Code:

#!/bin/bash

BASEURL="http://downloads.sourceforge.net/project/bitcoin/Bitcoin/bitcoin-0.7.0/"
FILES="bitcoin-0.7.0-linux.tar.gz bitcoin-0.7.0-macosx.dmg bitcoin-0.7.0-win32-setup.exe bitcoin-0.7.0-win32.zip"
SIGNATURE="SHA256SUMS.asc"
TMPFILE="hashes.tmp"

for file in in $FILES $SIGNATURE
do
   wget --quiet -N "$BASEURL$file"
done

#check signature
gpg --decrypt SHA256SUMS.asc > "$TMPFILE" 2>/dev/null

if [ $? -ne 0 ]
then
   echo "Bad signature."
   exit 1
fi

#check hashes
diff <(sha256sum $FILES) hashes.tmp > /dev/null

if [ $? -eq 1 ]; then
   echo "Hashes don't match."
   exit 1
elif [ $? -gt 1 ]; then
   echo "Error executing 'diff'"
   exit 2   
fi

#everything matches up! clean up the mess
for file in $FILES $SIGNATURE $TMPFILE
do
   rm "$file"
done

exit 0

A better way than hard coding file names would probably be pulling the newest version of SHA256SUMS.asc, and downloading the files specified in there. But I don't know how to get a direct URL for the newest version of a file on SourceForge.
http://sourceforge.net/projects/bitcoin/files/latest/download redirects to http://heanet.dl.sourceforge.net/project/bitcoin/Bitcoin/bitcoin-0.3.24/bitcoin-0.3.24-src.tar.gz which seems very... not latest.

EDIT: You need to have Gavin's GPG key imported on your system for this script to work. This will do it:

Code:

wget http://bitcoin.org/gavinandresen.asc
gpg --import gavinandresen.asc

[1714044079]

1714044079

[1714044079]

1714044079

[1714044079]

1714044079

[1714044079]

1714044079

[1714044079]

1714044079

[befuddled]

I pasted that script into a file, ran it, and after a couple of minutes it exited and said "Bad signature."

Edit:
if I just run gpg --decrypt SHA256SUM.asc it shows:

Code:

---@jefferson:~/bitcoin$ gpg --decrypt SHA256SUMS.asc
4b7a44fec28cbd9194a1303dd65bba8f13aa2facd4e06e4a3d1df6d66bc1deb5  bitcoin-0.7.0-linux.tar.gz
8c2c2a9dcccb39489a1c3e0bd6e8d8c0efc8aad7889af5aa361e21ec3aa86080  bitcoin-0.7.0-macosx.dmg
9572c2f21d3f4282d9e855f7798cb4d903e900d59358ce03ce695e040090b28c  bitcoin-0.7.0-win32-setup.exe
f0bdf431928e4000ac23e2299bdf32ef8a6b5adc25497a7bacb079abab7a7f18  bitcoin-0.7.0-win32.zip
gpg: Signature made Fri 21 Sep 2012 02:13:56 PM CDT using RSA key ID 1FC730C1
gpg: Can't check signature: public key not found

I've never used pgp, and don't really understand signatures. How does it find the public key? Problem on my end I'm guessing.

[runeks]

Oh, woops. I forgot to add that you need to have Gavin's key imported for this to work. Do this:

Code:

wget http://bitcoin.org/gavinandresen.asc
gpg --import gavinandresen.asc

I'll add it to the original post.

[foo]

Oh, woops. I forgot to add that you need to have Gavin's key imported for this to work. Do this:

Code:

wget http://bitcoin.org/gavinandresen.asc
gpg --import gavinandresen.asc

I'll add it to the original post.

Or you can get the key from a keyserver. May be safer?

Code:

gpg --keyserver pgp.mit.edu --recv-keys 1FC730C1

[runeks]

I've updated the script. Now you only need to specify the URL of the SHA256SUMS.asc file in question. It first downloads this file and checks the signature. After that it downloads all the files specified in the signature file and checks the hashes of these files.

Code:

#!/bin/bash

WORKINGDIR="/tmp/bitcoin"
TMPFILE="hashes.tmp"

SIGNATUREFILE="http://downloads.sourceforge.net/project/bitcoin/Bitcoin/bitcoin-0.7.1/test/SHA256SUMS.asc"

if [ ! -d "$WORKINGDIR" ]; then
   mkdir "$WORKINGDIR"
fi

cd "$WORKINGDIR"

GPGOUT=$(curl --silent -L "$SIGNATUREFILE" | gpg --yes --decrypt --output "$TMPFILE" 2>&1)

if [ $? -ne 0 ]
then
   echo "Bad signature."
   echo "gpg output:"
   echo "$GPGOUT"|sed 's/^/\t/g'
   exit 1
fi

FILES=$(awk '{print $2}' "$TMPFILE")
BASEURL="${SIGNATUREFILE%/*}/"

for file in in $FILES
do
   wget --quiet -N "$BASEURL$file"
done

#check hashes
DIFF=$(diff <(sha256sum $FILES) "$TMPFILE")

if [ $? -eq 1 ]; then
   echo "Hashes don't match."
   echo "Offending files:"
   echo "$DIFF"|grep "^<"|awk '{print "\t"$3}'
   exit 1
elif [ $? -gt 1 ]; then
   echo "Error executing 'diff'"
   exit 2   
fi

#everything matches! clean up the mess
for file in $FILES $TMPFILE
do
   rm "$file"
done

exit 0

[flatfly]

Hmmm.. Perhaps a stupid question, but how do you verify the verifying script?

[Foxpup]

Hmmm.. Perhaps a stupid question, but how do you verify the verifying script?

I'm afraid Ken Thompson has some bad news for you.

[🏰 TradeFortress 🏰]

Bitcoin probably will be the next target but people should catch on.

[Gavin Andresen]

I've updated the script. Now you only need to specify the URL of the SHA256SUMS.asc file in question.

Nice! You should submit a pull request to put a version of this in the contrib/ directory; my only suggestion would be to make it take a version string as an argument (and maybe automatically look in the test/ subdirectory if it contains 'rc').

[runeks]

I've updated the script. Now you only need to specify the URL of the SHA256SUMS.asc file in question.

Nice! You should submit a pull request to put a version of this in the contrib/ directory; my only suggestion would be to make it take a version string as an argument (and maybe automatically look in the test/ subdirectory if it contains 'rc').

Good idea.

I've updated the script to allow specifying a version string (which looks in the test/ dir if it ends with "-rc[0-9]") and made the pull request: https://github.com/bitcoin/bitcoin/pull/1935

Now we just need Bitcoin-interested people with a server to run this script at timed intervals, and we have ourselves a distributed Bitcoin-executable verification system.

[runeks]

Hmmm.. Perhaps a stupid question, but how do you verify the verifying script?

I will be signing the script, and will make an additional script that verifies this. After that I plan on making a third script that verifies a signature over the second script. Once this is completed, the logical next step is making a script that verifies a signature over the third script. All this will - of course - be useless without the fifth script that verifies the fourth one. So, in the end  - if time permits - I will make an infinite number of scripts that will make sure you can trust the first one.

[justusranvier]

I had an idea while reading this thread but don't know if it's mathematically possible.

The official binaries are produced from a deterministic process that could be though of as a function that takes a git commit id as an input and produces a checksum of the compiled result as an output.

When an individual signs a release he is effectively asserting "F(X)=Y" for a specific X and Y.

What if it were possible to construct a bitcoin address (A) such that if the address was used to sign the statement "F(X)=Y" and if that statement was not true, a third party could use a combination of the signature, F, and A to derive the private key and thus take any Bitcoins which had been sent there?

If it was possible to generate such an address it could be used to insure builds. Any person who signs a false statement risks having the coins he offered up as insurance taken by the first person to discover the falsehood.

[cypherdoc]

Hmmm.. Perhaps a stupid question, but how do you verify the verifying script?

I will be signing the script, and will make an additional script that verifies this. After that I plan on making a third script that verifies a signature over the second script. Once this is completed, the logical next step is making a script that verifies a signature over the third script. All this will - of course - be useless without the fifth script that verifies the fourth one. So, in the end  - if time permits - I will make an infinite number of scripts that will make sure you can trust the first one.

 

[chsados]

Why not use torrent/magnet link - or am i missing some vulnerability there?

A trusted user posts the torrent file at some location and we all seed.

[jgarzik]

Why not use torrent/magnet link - or am i missing some vulnerability there?

A trusted user posts the torrent file at some location and we all seed.

The point of using PGP signatures is that a "trusted user" can be impersonated.

Speaking of seeding, though, there is an experimental bitcoin blockchain torrent.

[runeks]

Why not use torrent/magnet link - or am i missing some vulnerability there?

A trusted user posts the torrent file at some location and we all seed.

The threat is that the trusted location - as in SourceForge, or bitcoin.org - is hacked. Whether this trusted location points to a torrent magnet URI or an executable downloaded via HTTP isn't relevant.

But you remind me that it's also relevant to crawl bitcoin.org. If an adversary hacks bitcoin.org and makes the Bitcoin client download URL point to a file hosted by himself, we wouldn't notice with this script. So I guess that's another feature that this surveillance system should have.

[paraipan]

Why not use torrent/magnet link - or am i missing some vulnerability there?

A trusted user posts the torrent file at some location and we all seed.

Great idea, the magnet links contain a cryptographic hash of the file.

http://en.wikipedia.org/wiki/Magnet_URI_scheme

The Magnet URI scheme is a de facto standard (instead of an open standard) defining a URI scheme for Magnet links, which mainly refer to resources available for download via peer-to-peer networks. Such a link typically identifies a file not by location, but by content -- more precisely, by the content's cryptographic hash value.

So Gavin could sign it with his key and share on the forum and sourceforge and we all get to check for the main client integrity even if a central download server is hacked. The nice thing is all torrent clients know how to handle them and start looking for peers and download the main client without issues.

[chsados]

Why not use torrent/magnet link - or am i missing some vulnerability there?

A trusted user posts the torrent file at some location and we all seed.

Great idea, the magnet links contain a cryptographic hash of the file.

http://en.wikipedia.org/wiki/Magnet_URI_scheme

The Magnet URI scheme is a de facto standard (instead of an open standard) defining a URI scheme for Magnet links, which mainly refer to resources available for download via peer-to-peer networks. Such a link typically identifies a file not by location, but by content -- more precisely, by the content's cryptographic hash value.

So Gavin could sign it with his key and share on the forum and sourceforge and we all get to check for the main client integrity even if a central download server is hacked. The nice thing is all torrent clients know how to handle them and start looking for peers and download the main client without issues.

exactly...any change to the file and the torrent wont download - similar to the way blockchain works

[jimbobway]

Does this script take into account all of the mirrors?