Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

release: Add all artifact files to checksums file #1588

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

duthils
Copy link
Contributor

@duthils duthils commented Aug 24, 2024

As discussed in #1539, the checksum file is missing Linux packages and, as a matter of fact, a few more files like the SBOM artifact.

As stated in the goreleaser documentation for the release.ids setting:

 # IDs of artifacts to include in the checksums file.
 #
 # If left empty, all published binaries, archives, linux packages and source >archives
 # are included in the checksums file.
 ids:
   - foo
   - bar

As a result, before the change, I got this checksum file (simplified) sops-v3.9.0.checksums.txt:

7babe10020e086d7b3c2c6f18c448f86a38be24ac110bce3fb1808b7fe6ab30e  sops-v3.9.0.linux.amd64

After the change:

4b4885d28983e95d0760314322c7e7880860337e59eb8e974ec11391bcc50924  sops-3.9.0-1.x86_64.rpm
7babe10020e086d7b3c2c6f18c448f86a38be24ac110bce3fb1808b7fe6ab30e  sops-v3.9.0.linux.amd64
4afe01e7753e7d69c83475d3573a26885fcc638dde3cebc8a8deef766d047fed  sops-v3.9.0.linux.amd64.spdx.sbom.json
30dca2065cb68204381042c69c0dc54c6cd3b4842674046f2e9fcaa5a79999a6  sops_3.9.0_amd64.deb

For reference, the release.ids value in sops was introduced in the first version of the goreleaser config file: 02de4a8

@felixfontein
Copy link
Contributor

@hiddeco since you know a lot more about goreleaser, can you take a look at this one?

@duthils
Copy link
Contributor Author

duthils commented Sep 14, 2024

I have rebased the branch

@felixfontein felixfontein added this to the 3.9.1 milestone Sep 14, 2024
@hiddeco
Copy link
Member

hiddeco commented Sep 25, 2024

The reason I omitted the SBOMs is that they can still be verified using SLSA which is IMHO far superior to checksum verification.

There is no special reason for the packages, but I do recall something about not all names in the generated checksum file being true to their name as published for the release and/or there being duplicate entries without providing an explicit list.

@felixfontein felixfontein modified the milestones: 3.9.1, Maintenance work Oct 3, 2024
@duthils
Copy link
Contributor Author

duthils commented Oct 7, 2024

So for me, the question is:

  • do we want to keep checksums.txt, since intoto.jsonl includes the checksums?
  • If yes, do we leave it in the current state where only some files are included in checksums.txt, or do we include all files?

I would recommend keeping only intoto.jsonl and dropping checksums.txt altogether, since SLSA verification is better, and checksums.txt is redundant.

The release documentation would need to be updated though, to explain that binary integrity should be verified through SLSA verification. I will open another PR in that direction.

@duthils
Copy link
Contributor Author

duthils commented Oct 7, 2024

Here is the alternative PR to remove checksums.txt and associated files: #1643

@er0k
Copy link

er0k commented Oct 8, 2024

Since sha256sum/shasum is so ubiquitous I think a checksums.txt is quite helpful, especially on systems where slsa-verifier may not be available or allowed (such as restrictive corporate environments, or air gapped systems).

Why:

* goreleaser will automatically include all relevant checksums in the checksum
  file

Signed-off-by: Sebastien Duthil <[email protected]>
@duthils
Copy link
Contributor Author

duthils commented Oct 9, 2024

I'm fine with that option as well. Since both PR are open, we only need to merge one and close the other.

I have rebased the branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants