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.
21 lines
1.0 KiB
Bash
Executable File
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
|