Problem
The public build/release workflows currently reference actions through mutable major-version tags, including:
actions/checkout@v4;actions/upload-artifact@v4;actions/download-artifact@v4;microsoft/setup-msbuild@v2;- third-party
miurahr/install-linuxdeploy-action@v1.
The build jobs themselves are mostly read-only, but their outputs cross a trust boundary: the write-capable publisher later downloads those artifacts and distributes them through semper-exp-current. A compromised/moved action tag in a read-only producer can therefore poison an artifact that the privileged publisher faithfully publishes.
Required hardening
Pin every action used on the build/publication/source-snapshot path to a full immutable commit SHA, with an adjacent comment recording the intended human version (for example # v4.x.y).
Treat the third-party LinuxDeploy installer as the highest-priority pin/review because it executes code during production of the Linux binary package.
Where practical, verify the pinned commit corresponds to the intended upstream release/tag before adopting it. Updates should be explicit reviewable dependency bumps, not implicit movement of a major tag.
Acceptance
- no release-path
uses: entry relies only on a mutable branch/major tag;
- every pin is a 40-character commit SHA with a human-readable version comment;
- the exact pins are reviewed against their upstream repositories/releases;
- changing an action version produces an ordinary repository diff and review event;
- PR build/test behavior remains available;
- no private validation material or engine-semantic changes are involved.
Follow-up / optional
After immutable pinning, evaluate whether GitHub artifact attestations/provenance add useful assurance for the public binaries. Do not make attestation work a blocker for the simpler SHA-pinning control.
Problem
The public build/release workflows currently reference actions through mutable major-version tags, including:
actions/checkout@v4;actions/upload-artifact@v4;actions/download-artifact@v4;microsoft/setup-msbuild@v2;miurahr/install-linuxdeploy-action@v1.The build jobs themselves are mostly read-only, but their outputs cross a trust boundary: the write-capable publisher later downloads those artifacts and distributes them through
semper-exp-current. A compromised/moved action tag in a read-only producer can therefore poison an artifact that the privileged publisher faithfully publishes.Required hardening
Pin every action used on the build/publication/source-snapshot path to a full immutable commit SHA, with an adjacent comment recording the intended human version (for example
# v4.x.y).Treat the third-party LinuxDeploy installer as the highest-priority pin/review because it executes code during production of the Linux binary package.
Where practical, verify the pinned commit corresponds to the intended upstream release/tag before adopting it. Updates should be explicit reviewable dependency bumps, not implicit movement of a major tag.
Acceptance
uses:entry relies only on a mutable branch/major tag;Follow-up / optional
After immutable pinning, evaluate whether GitHub artifact attestations/provenance add useful assurance for the public binaries. Do not make attestation work a blocker for the simpler SHA-pinning control.