Include torrent in binary download verification

Sjors commented at 11:26 am on May 19, 2023: member

The binary verification script currently covers bitcoin(core).org but not the torrents. We should add an option to download and verify those as well.

fanquake added the label Scripts and tools on May 19, 2023

MarcoFalke commented at 10:50 am on September 15, 2023: member

Closing for now, because the corresponding pull seemed stale and was just closed as well.

Not sure why there needs to be a script in this repo at all to download a file, and why it needs to be combined into the verify-binary.py script. It shouldn’t matter where the file comes from. You could have it shipped to you on a persistent storage medium.

It seems best to keep the download logic in separate scripts for each network (ipv4/6, torrent, tor, ipfs, …). Also, if there is need to have it (in one script or multiple scripts), it could make more sense to have it in a separate repo?

MarcoFalke closed this on Sep 15, 2023

Sjors commented at 4:03 pm on September 15, 2023: member

The problem is that our Guix builds don’t commit to the torrent hash. So the only way to verify if the torrent distribution isn’t tampered with, is to download and verify the binaries inside of it.

We don’t distribute the binaries over IPFS afaik.

It would make sense to at least download from the hidden service and see if the downloads match what we provide over .org. For the .org I suppose it could make sense to download both over IPv4 and IPv6 and check that they match.

MarcoFalke commented at 9:44 am on September 17, 2023: member

download both over IPv4 and IPv6 and check that they match.

I don’t understand the logic where the source (or transport protocol) of a file is used to verify the file. My understanding is that there is a checksum file included, which can help to catch non-malicious file corruption. Also, the checksum file can be signed by people you trust (or by yourself if you guix-build yourself), which can help to catch malicious file (and checksum file) corruption.

Sjors commented at 10:33 am on September 19, 2023: member

There’s two forms of checking:

By individual users, they can use the signed checksum file
By people keeping an eye on bitcoincore.org to see if it’s compromised.

I’m talking about (2) here. The easier such a check is, the better.

MarcoFalke commented at 10:57 am on September 19, 2023: member

Ok, I see. Let us know if this issue and/or #27762 should be reopened.

Sjors commented at 11:08 am on September 19, 2023: member

I’ll leave it up to @willcl-ark if he wants to reopen the PR, but let’s re-open this issue.

MarcoFalke reopened this on Sep 19, 2023

MarcoFalke added the label Brainstorming on Sep 19, 2023

willcl-ark commented at 9:29 am on September 26, 2023: contributor

It would make sense to at least download from the hidden service and see if the downloads match what we provide over .org. For the .org I suppose it could make sense to download both over IPv4 and IPv6 and check that they match. @Sjors sorry but I don’t understand exactly what you mean by this. Are you advocating for including torrent downloading facility inside of this verify script? If so then I still disagree and think this is highly undesirable.

So the only way to verify if the torrent distribution isn’t tampered with, is to download and verify the binaries inside of it.

What else are you suggesting should be done, apart from this?

Sjors commented at 1:32 pm on September 27, 2023: member

Are you advocating for including torrent downloading facility inside of this verify

Depends on what you mean by “facility”. I think we should download them if there’s a torrent download command on the system. Just like we download if wget / curl is on the system. But we should not add a (large) torrent Python dependency.

For that to work, we could either add the magnet link to the script or find it on bitcoincore.org.

What else are you suggesting should be done, apart from this?

I think (some or all of) the following are useful to check:

That bitcoincore.org does not link to a malicious torrent (i.e. check that the torrent hash matches what we expect)
That the binaries inside that torrent are the ones we expect (just based on the file checksums, since we already check them against guix signatures via the regular download part of the script)

willcl-ark commented at 1:37 pm on September 27, 2023: contributor

Depends on what you mean by “facility”. I think we should download them if there’s a torrent download command on the system. Just like we download if wget / curl is on the system. But we should not add a (large) torrent Python dependency.

I see, so we would do something like check to see if rtorrent or transmission-cli are found on PATH, and only proceed with the download and verification if they are? I think I could get behind that.

Sjors commented at 3:14 pm on September 27, 2023: member

Exactly(and only if the command is run with something like --torrent, which should explain that this will happen, since we don’t want to accidentally trigger some malware)

Include torrent in binary download verification #27702