Both snap packages and the CycloneDX SBOM ship with no checksum of any kind

[yusuf-gundogdu]

Checksums in a release are split two ways, and three payload assets fall through the gap.

Of the 16 payload assets in 0.15.0:

• 8 carry their own <name>.sha256 — the .deb, .rpm and AppImage files
• 5 are listed in the combined SHA256SUMS — the standalone archives
• 3 have neither:

libredb-studio-0.15.0.cdx.json
libredb-studio_0.15.0_amd64.snap
libredb-studio_0.15.0_arm64.snap

Reproduce:

gh api repos/libredb/libredb-studio/releases/latest --jq "[.assets[].name]" > assets.json
curl -sL "$(gh api repos/libredb/libredb-studio/releases/latest \
  --jq ".assets[]|select(.name==\"SHA256SUMS\")|.browser_download_url")" > sums.txt
python3 - <<PY
import json
n = json.load(open("assets.json")); sums = open("sums.txt").read()
payload = [a for a in n if not a.endswith(".sha256") and a != "SHA256SUMS"]
print([a for a in payload if (a + ".sha256") not in n and a not in sums])
PY

The snaps are the awkward ones: they are a documented install channel, so someone who downloads the .snap from the release page rather than through the Snap Store has nothing to check it against. The SBOM matters less in practice but it is the file a security reviewer is most likely to want a hash for.

Either extend SHA256SUMS to cover every payload asset, or emit a .sha256 for the three that lack one. Extending the combined file looks simpler and would also make the split easier to explain: right now a reader has to know which of the two mechanisms applies to the artifact they picked.

[Retsumdk]

Picking this up.

Plan, following the "extend the combined file" option: leave the publish job writing SHA256SUMS for the tarballs and the win32 zip exactly as it does today, and rebuild the file once in publish-release, where every payload asset finally exists. The rebuilt file covers all of them — both snaps and the CycloneDX SBOM included — and the .deb/.rpm/.AppImage sidecars stay exactly as they are.

Two points I would like to get right:

1. The rebuild takes each asset's sha256 digest from the releases API rather than downloading ~1.5 GB of release assets in the last job of the chain, and falls back to downloading and hashing an asset that has no digest recorded.
2. It asserts that every entry the file already carried is still there with the same hash, so the npx launcher and the Homebrew/Chocolatey/winget renderers cannot be reading changed values, and it fails the job rather than publishing if that does not hold.

That also means the two mechanisms in docs/DISTRIBUTION.md collapse into one: SHA256SUMS for everything, the sidecars left where they are. I will update that section in the same PR.

[Retsumdk]

Opened #918 for this.

Approach: leave the publish job generating SHA256SUMS for the tarballs/zip as it does today, then rebuild the file in publish-release from the draft's asset list — that is the first point at which the snaps and the SBOM exist, and the last point before the release is immutable. The rebuild covers every payload asset, takes each hash from the release asset's sha256 digest (falling back to hashing the downloaded bytes if an asset has none), and refuses to proceed if an entry already in the file would change, so the tarball/zip lines the launcher and Homebrew read stay exactly as they were.

[yusuf-gundogdu]

Closing this. These are being fixed directly rather than tracked as issues.