#19205 introduced signature verifying for the downloaded SHA256SUMS.asc.
This approach is brittle and does not work in CI environment for many reasons:
This PR:
Alternatively we might as well hard code the checksum for each
tar.gzrelease in the source code, here.
is an alternative to 5a2c31e528e6bd60635096f233252f3c717f366d (#19013)
fixes #19812
updates v0.17.1 to v0.17.2
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--174a7506f384e20aa4161008e828411d-->
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.
Concept ACK: this is better than than fetching the checksums from the same host as the binaries :)
Does this need a mention in the release process?
Does this need a mention in the release process?
This is only used by tests to download binaries, so no docs need to change. Maybe this should be moved to ./test/download_previous_releases.py or so?
Maybe this should be moved to
./test/download_previous_releases.pyor so?
Out from contrib/devtools/?
Concept ACK
Concept ACK. Maybe put the shasums in a text file so they're easier for other tools to use?
I'm aware of that. I meant to add the hashes to the Python script.
Concept ACK. Maybe put the shasums in a text file so they're easier for other tools to use?
-0 on this. I mean, the preferred way to validate downloaded binaries is still using GPG, and while I think this is a good shortcut to optimize CI, I'm not sure we should encourage its use in other tools.
I'm aware of that. I meant to add the hashes to the Python script.
Sorry. It seems I did not understand correctly your initial suggestion:
Does this need a mention in the release process?
Mind rewording?
The tests will need to be adjusted anyway to use the new binaries, so the hashes can be added then (if needed)
No, it's okay, I agree with @MarcoFalke that that is not needed.
This is only used by tests to download binaries, so no docs need to change.
-BEGIN VERIFY SCRIPT-
OLD=contrib/devtools/previous_release.py
NEW=test/get_previous_releases.py
sed -i "s|$OLD|$NEW|g" $(git grep -l $OLD)
git mv $OLD $NEW
-END VERIFY SCRIPT-
Updated c5affe70902ccf6ced959c8424cf7f35a3e5e6e1 -> 0374e821bd9e9498ce9c03aa8e5435870019978b (pr19813.01 -> pr19813.02, diff).
Addressed @MarcoFalke' comment:
This is only used by tests to download binaries, so no docs need to change. Maybe this should be moved to
./test/download_previous_releases.pyor so?
cr ACK 0374e821bd9e9498ce9c03aa8e5435870019978b
Hardcoding the hashes is equivalent from a trust perspective to hardcoding a gpg fingerprint and adding it to a keyring with ultimate trust.
The hashes will need to be updated whenever a new previous release is added to the tests, but that seems acceptable.
I noticed gitian building old releases doesn't match anymore, but since this only affects the downloader script (not the tests themselves), concept ACK.
I noticed gitian building old releases doesn't match anymore
guix fixes this (maybe)
tACK 0374e821bd9e9498ce9c03aa8e5435870019978b