Action fetches release installer via curl … | sh without verifying the script itself #198

Activity

1. untitaker commented on Jun 11, 2026

   

   untitaker

   on Jun 11, 2026 via email

   Owner

   More actions

   that works for me, patches welcome

   …

   On 11 June 2026 02:47:23 CEST, Jarek Potiuk ***@***.***> wrote: potiuk created an issue (untitaker/hyperlink#198) The composite action's `scripts/install.sh` pipes the release installer straight into `sh`: ```sh curl --proto '=https' --tlsv1.2 -LsSf https://github.com/untitaker/hyperlink/releases/download/$tag/hyperlink-installer.sh | sh ``` The cargo-dist installer does verify the downloaded binary against embedded checksums, so the *binary* is covered — but the installer **script** itself is fetched and executed unverified. Each release already ships `sha256.sum` and per-asset `.sha256` files, so the action could download `hyperlink-installer.sh` to a file, check it against a published checksum, then run it — closing the one unverified step. Context: this surfaces in downstream review at apache/infrastructure-actions#916, where every pinned-SHA bump of an allowlisted action is re-reviewed (rebuild/verify each download). The pattern is unchanged from the previously-approved 0.2.0, so it's not a regression — just flagging it as a hardening opportunity. Happy to send a PR if a checksum-then-run flow works for you. -- Reply to this email directly or view it on GitHub: #198 You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>
2. untitaker commented on Jun 11, 2026

   

   untitaker

   on Jun 11, 2026

   Owner

   More actions

   Each release already ships sha256.sum and per-asset .sha256 files, so the action could download hyperlink-installer.sh to a file, check it against a published checksum

   so the actions.yml still fetches the shellscript + its checksum from the same release?

   i am not sure if this actually buys you anything. the shellscript and the checksum are both just files in a release that is entirely mutable.

   I think it would make more sense to bake the sha into the actions.yml somehow, but that's a more complicated change
3. untitaker

   added

   help wantedThis is a call for feedback or is not going to happen without third-party contributionThis is a call for feedback or is not going to happen without third-party contribution

   on Jun 12, 2026
4. potiuk commented on Jun 27, 2026

   

   potiuk

   on Jun 27, 2026

   Last edited by potiuk

   ContributorAuthor

   More actions

   Fair point — fetching the script and its checksum from the same mutable release is circular, agreed.

   The clean way to anchor trust outside the release is GitHub's build attestations, which dist supports natively: github-attestations = true in dist-workspace.toml (since cargo-dist 0.16; you're on 0.30.2). Each release artifact then gets a Sigstore-backed SLSA attestation recorded in GitHub's transparency log — immutable and independent of the release assets. scripts/install.sh can fetch hyperlink-installer.sh to a file and run gh attestation verify on it before executing (gh is preinstalled on GitHub runners).

   I've opened #201 (draft) with exactly that change — happy to iterate on the details (token handling in the action env, and which artifacts get attested).
5. untitaker commented on Jun 27, 2026

   

   untitaker

   on Jun 27, 2026

   Owner

   More actions

   should be addressed by #201 -- as part of that discussion it seems we have a bit of tech debt around releases though. should probably upgrade node in our workflows, and upgrade dist too.
6. untitaker

   closed this as completedon Jun 27, 2026
7. potiuk commented on Jun 29, 2026

   

   potiuk

   on Jun 29, 2026

   ContributorAuthor

   More actions

   All work BTW. Thanks.

   👍React with 👍1Reacted by Markus Unterwaditzer