Closes #27702
Adds functionality to the verify-binary.py script to verify the signatures in a torrent download.
Users must download the torrent themselves manually and point the script to the directory using the torrent subcommand.
The syntax chosen was ./contrib/verify-binaries/verify.py torrent <path to SHA256SUMS file>
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
See the guideline for information on the review process. A summary of reviews will appear here.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
465- good_untrusted: t.List[SigData],
466- unknown: t.List[SigData],
467- bad: t.List[SigData],
468- files_to_hashes: t.Dict[str, str],
469- missing_files=None,
470- ):
484@@ -481,9 +485,8 @@ def print_output(
485 else:
486 for filename in files_to_hashes:
487 print(f"VERIFIED: {filename}")
488- if missing_files:
489- for filename in missing_files:
490- print(f"MISSING: {filename}")
491+ for filename in missing_files:
Successfully tested on macOS 13.4 against v25.0.
Lightly code reviewed a6dcf2cb0817143beacf0b9004191a0dd6d2e43c.
Do we want to use the .asc file from the torrent, or should we just get it from the Guix signature repo? The latter may have more signatures, as they keep coming in after release.
Do we want to use the .asc file from the torrent, or should we just get it from the Guix signature repo? The latter may have more signatures, as they keep coming in after release.
I agree that the guix sig repo will likely have more signatures, I only worry that for privacy-concious folks, for whom either bitcoincore.org is blocked or they wish to remain hidden, automatically pinging a (different) specific website might not be ideal behaviour… What do you think?
edit: It’s just occurred to me that the torrent and bitcoincore.org .asc files are the same, so if we really wanted to start fetching additional signatures from GitHub (and appending them to the user-provided .asc), we should apply it to the `pub`` sub-command too? I don’t feel that’s right for this script, personally…
Requires torrent to be downloaded externally to this script.
Do we want to use the .asc file from the torrent, or should we just get it from the Guix signature repo? The latter may have more signatures, as they keep coming in after release.
It’s pros and cons. Repo will have more signatures, but any centralized server is single point of failure, torrents are better in this regard.
Sure there are tradeoffs.
It also seems problematic in that fetching them in any sane way would require git to be installed on the host machine (so we could e.g. do a sparse checkout of the release sub-directory). Alternatively just download the entire repo as .zip and go from there? Both seem undesirable/“messy” to me personally. 🤷🏼♂️
In the case of Github, I believe you can get individual raw files too.
But there’s something to be said for not being dependent on having Git installed, and also have the option to not download if you used a torrent before. So maybe we can have a --signatures-from-repo like option in that case? For non-torrent imo this should be true by default if git is installed. For torrents the option could be suggested.
OK I implemented as you suggested @Sjors. It does seem like a win to get more signatures on balance.
If people feel the approach is OK, and that it belongs in this PR (and not its own), I can probably tidy it up further as theres still some duplicated code which can probably be factored out.
from guix.sigs repo
Enabled automatically for `pub` and `bin`, but disabled for `torrent` to
for maximum privacy.
Can be toggled using the --signatures-from-repo option.
876 bin_parser.add_argument(
877 "binary", nargs="*",
878 help="Path to a binary distribution file to verify. Can be specified multiple times for multiple files to verify."
879 )
880
881+ torrent_parser = subparsers.add_parser("torrent", help="Verify local torrent dir (requires manual torrent download).")
torrent different from bin (verify local binaries)?
Right, without performing the actual torrent download it ends up being the same!
I’m going to close this for now as IMO it doesn’t make sense to pull in a large python torrent lib just to perform the download in this verification script. Perhaps we close #27702 as well, unless we really want this.
If there was appetite to add a python-based torrent download, I’d be happy to work on it…
A python-based torrent download may also be useful for downloading an AssumeUTXO snapshot, though in the long run we may use another method to distribute.
pull in a large python torrent lib
If we go that route, it should be an optional dependency for this script.
Another approach could be to look for some command torrent executables on the system, and tell the user to install something themselves if not present.