Attest and checksum what actually ships - #48
Merged
Conversation
Verifying the published 0.1.0 release, rather than the build output, falsified both commands SECURITY.md tells an adopter to run. gh attestation verify on a downloaded release binary exits 1. The attestation named only the .nupkg files as subjects, so the three downloadable zips were never attested -- and those zips are what a person without the .NET SDK actually downloads. sha256sum -c SHA256SUMS.txt fails four of its seven entries. The file was generated across the whole build directory, so it listed the .nupkg and .snupkg files, which go to NuGet and are never attached to the release. Both now cover what ships: the zips are attestation subjects alongside the packages, and the checksum file is generated over the release assets only. The cause is worth recording because it is the same mistake this project keeps writing about. The verification instructions were checked -- against the rehearsal artifacts directory, which contains the packages. Both commands passed there and failed in reality. Testing in the wrong environment is indistinguishable from not testing, right up until someone follows the documentation. 0.1.0 is published and immutable, so SECURITY.md now says which release each command applies to and gives the form that does work today: sha256sum -c --ignore-missing SHA256SUMS.txt, confirmed against the real 0.1.0 assets, reports OK for all three binaries.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Verifying the published 0.1.0 release — rather than the build output — falsified both commands
SECURITY.mdtells an adopter to run.Two defects, both shipped in 0.1.0
gh attestation verifyon a downloaded release binary exits 1. The attestation named only the.nupkgfiles as subjects, so the three downloadable zips were never attested. Those zips areexactly what someone without the .NET SDK downloads.
sha256sum -c SHA256SUMS.txtfails four of seven entries. The file was generated withsha256sum *across the whole build directory, so it lists the.nupkgand.snupkgfiles, whichare published to NuGet and never attached to the release.
The fix
Attestation subjects now include
artifacts/*.zipalongside the packages, and the checksum file isgenerated over
*.zip— the release assets — rather than the whole directory.Why this happened, since it is the same mistake this project keeps writing about
The verification instructions added in #46 were checked before shipping — against the rehearsal
artifacts directory, which contains the packages. Both commands passed there and failed in reality.
Testing in the wrong environment is indistinguishable from not testing, right up until someone
follows the documentation.
0.1.0 is immutable, so the docs now say what is true of it
NuGet packages cannot be withdrawn and the release is public.
SECURITY.mdstates which releaseeach command applies to, and gives the form that works on 0.1.0 today — verified against the real
published assets, this time:
It also states plainly that 0.1.0's unattested binaries are a packaging mistake rather than a
tampered file: they were produced by the same workflow run, and their digests are in that release's
SHA256SUMS.txt.Verification
229 tests green.
release.ymlparses as valid YAML with the intendedsubject-pathand checksumcommand. All relative links resolve.