Add script to contrib/ that verifies authenticity of binaries hosted on SourceForge #1935

runeksvendsen commented at 8:48 PM on October 15, 2012: contributor

This script downloads the SHA256SUMS.asc file from SourceForge for a given release (version can be specified on the command line), which contains Gavin's signature of the hashes of the Bitcoin binaries. It verifies that the signature is valid, downloads the files specified in the signature file, and checks that the hashes of these files match with those signed by Gavin.

Added script that verifies authenticity of binaries on SourceForge de91ea0c0c

in contrib/verifysfbinaries/verify.sh:None in de91ea0c0c

  80 | +   if [ $RET -eq 1 ]; then
  81 | +      #and notify the user if it's bad
  82 | +      echo "Bad signature."
  83 | +   elif [ $RET -eq 2 ]; then
  84 | +      #or if a gpg error has occured
  85 | +      echo "gpg error. Do you have Gavin's code signing key installed?"

luke-jr commented at 9:06 PM on October 15, 2012:

Not all releases are signed by Gavin (notably stable/backport releases are not), and users probably shouldn't be expected to setup the key themselves anyway. There are a bunch of PGP keys in git already for verifying against - any way to use those easily?

runeksvendsen commented at 10:10 PM on October 15, 2012:

0.7.0 is signed by Gavin. Is that not a stable release? I considered including installation of the key in the script, but I figured it was preferable to let the users install these by themselves. But now that you point it out, I'm not sure why the script shouldn't just install if it reaches the line above.

Where are those PGP keys in git that you mention? Also, I'd have to know who signs what with which keys in order to know how to use them.

It would be better if all the heavily involved developers sign the executables. That way it'd be even harder for an attacker to somehow get past this (by getting hold of Gavin's key, for example).

luke-jr commented at 11:21 PM on October 15, 2012:

0.7.0 is a first-time stable release: it's built off master, not a stable branch.

I wouldn't suggest touching the user's PGP setup, but verifying without touching it. If GPG really needs to keep keys somewhere, ~/.bitcoin/.gnupg or similar makes sense.

contrib/gitian-downloader contains PGP keys. There's also a git repository here on GitHub with signatures of multiple developers for most releases which would be better to use than the SHA256SUMS file (which can only have one signature).

gavinandresen commented at 11:32 PM on October 15, 2012:

... but we don't want Runek to end up reinventing gitian-downloader, and I hate making 'perfect the enemy of the good'.

So I vote this gets pulled as-is, because it is much better than the nothing we have now.

runeksvendsen commented at 11:35 PM on October 15, 2012:

I wouldn't suggest touching the user's PGP setup, but verifying without touching it. If GPG really needs to keep keys somewhere, ~/.bitcoin/.gnupg or similar makes sense.

OK. Then I misunderstood you. So you're saying the script should pull in a public key from a remote location and use that to verify? That makes sense. This would create another point of attack though. I figured the best way was to let the users who run the script store the keys themselves, so these can't be modified easily by an adversary.

contrib/gitian-downloader contains PGP keys. There's also a git repository here on GitHub with signatures of multiple developers for most releases which would be better to use than the SHA256SUMS file (which can only have one signature).

The threat that this script tries to mitigate is that of an adversary replacing the binaries on SourceForge (I made it after reading this thread: https://bitcointalk.org/index.php?topic=113018.0). So the devs in question need to sign the binaries that are linked to on bitcoin.org. Is this the case wrt. to the git repo you're referencing? As far as I can see, this is not what is signed in this repo at least: https://github.com/bitcoin/gitian.sigs/ - is this the repository you're talking about?

luke-jr commented at 11:44 PM on October 15, 2012:

No, since this script is going into the git repository, it should be able to assume it has the PGP keys in that directory already. I just mean touching the user's personal PGP key library is probably a bad idea.

https://github.com/bitcoin/gitian.sigs should match the binaries on SF: the installers as-is, and the contents of the ZIP files and tarballs. @gavinandresen ACK, you're right this would probably end up equivalent and doesn't do any harm to pull as-is.

BitcoinPullTester commented at 4:33 AM on October 19, 2012: none

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/de91ea0c0c2fead60bfe9a531558cbe1c562346e for binaries and test log.

gavinandresen referenced this in commit a77bcaddbf on Oct 29, 2012

gavinandresen merged this on Oct 29, 2012

gavinandresen closed this on Oct 29, 2012

laudney referenced this in commit eb4a5c2cbd on Mar 19, 2014

KolbyML referenced this in commit 47916129bc on Dec 5, 2020

DrahtBot locked this on Sep 8, 2021