Files
dc/.gitea/scripts/verify-section.sh
T
dc f1ae501d49
Build / Build-and-ng-test (pull_request) Successful in 5m20s
Lighthouse Checks / lighthouse (pull_request) Successful in 21m10s
Build / Build-and-test-development (pull_request) Successful in 25m20s
feat(release): publish SHA256SUMS and verify instructions with each release
The release job now hashes every asset it uploads (frontend.zip, the SAS 9
and Viya deployment programs, the SASjs Server bundle) into a SHA256SUMS
file with basename-only paths, and attaches it to the release alongside
the assets. The release body gains a "Verifying the download" section -
emitted by .gitea/scripts/verify-section.sh so the YAML scalar stays
clean - with the sha256sum -c command and a note on what a checksum does
and does not prove.

The upload loop is rewritten from an inline list to a bash array shared
by the hashing and upload steps, so the asset set cannot drift between
what is hashed and what is uploaded.

Simulated end to end locally (stubbed curl/jq): 8 uploads fire with
correct paths, SHA256SUMS verifies with sha256sum -c, a tampered file
fails the check, and the assembled release body keeps the existing
notes with the new section and installation footer on their own lines.
2026-09-24 22:30:36 +00:00

21 lines
1.0 KiB
Bash
Executable File

#!/usr/bin/env bash
# Emits the "Verifying the download" section appended to every release body
# by the "Upload assets to release" step of release.yaml.
# Keep this text in sync with the docs page:
# docs.datacontroller.io/docs/downloads.md
set -euo pipefail
cat <<'EOF'
## Verifying the download
Every asset on this release is covered by the `SHA256SUMS` file. To verify a download, fetch `SHA256SUMS` from the release assets alongside the files you downloaded, then run:
```
sha256sum --check SHA256SUMS --ignore-missing
```
The command reports `OK` for each asset that matches. `--ignore-missing` lets you check just the files you downloaded rather than all of them.
What this protects: a matching checksum confirms the asset is byte-for-byte the file this pipeline uploaded, guarding against corrupted or tampered downloads (mirrors, proxies, interrupted transfers). It is not a signature: the hashes travel in the same release as the files, so a compromise of the forge itself could alter both. Treat it as an integrity check, not a trust anchor.
EOF