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

[potiuk]

The composite action's scripts/install.sh pipes the release installer straight into 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.

[untitaker]

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: ***@***.***>

[untitaker]

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