Uh oh!
There was an error while loading. Please reload this page.
ci: pin actions to full commit SHAs, drop setup-xcode - #4
Merged
Conversation
Mutable tags let an upstream retag execute new code in our jobs. That matters most in mac.yml, where the third-party setup-xcode runs in the same job that later holds the Developer ID p12, the notary key and HOMEBREW_TAP_TOKEN. Each SHA is the commit the tag pointed at, with the version in a trailing comment so bumps stay reviewable. setup-xcode's v1 is an annotated tag, so this is the dereferenced commit, not the tag object.
The signing job holds the Developer ID key, the notary key and HOMEBREW_TAP_TOKEN; a pin freezes what a third-party action ships but not what it can read. Selecting Xcode is a one-liner, so do it inline and remove the dependency instead. Dependabot keeps the remaining SHA pins from rotting — it bumps the SHA and the version comment together, grouped into a single weekly PR.
Uh oh!
There was an error while loading. Please reload this page.
This was referenced Jul 29, 2026
z33b0t added a commit
that referenced
this pull request
Jul 29, 2026
The release path produced a notarized macOS zip, a Windows zip and a sha256 in the Homebrew cask, none of it tied back to the run or commit that built it. A checksum proves the file didn't change in transit; anyone who can write to the release (or the tap) can publish a consistent zip-plus-checksum pair. Notarization proves Apple saw the binary and that it carries our Developer ID — it says nothing about which source tree it was built from. Adds actions/attest-build-provenance (pinned to a SHA, per #4) to both release jobs, publishing a signed SLSA statement that binds the artifact digest to the repo, workflow and commit: gh attestation verify Blurt-macOS.zip --repo lightware-dev/blurt Scoped to release tags — attestation is about what we publish, and a PR build isn't. The version-less Blurt-<platform>.zip copies need no separate statement: they're byte-identical and attestations are keyed by digest, not filename. Per-job permissions widen to id-token: write + attestations: write. This matters more on the Windows side, where releases are unsigned (#9), so the attestation is currently the only cryptographic link between a download and this repository. It is not a substitute for signing, and neither defends against repo write access: an attacker who can push a tag gets CI to attest their payload. What both defend is a release asset replaced *without* a code push. Also fixes a README claim while adding the verification instructions: the Windows section said "grab the latest signed build", which has never been true — exactly the misreading #9 is about, and it was in the docs as well as the workflow. Closes#24 Co-authored-by: z33b0t <z33b0t@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Mutable action tags let an upstream retag execute new code in our jobs. That matters most in
mac.yml, where actions run in the same job that holds the Developer ID p12, the notary key andHOMEBREW_TAP_TOKEN.maxim-lobanov/setup-xcode. A pin freezes what a third-party action ships but not what it can read, and selecting Xcode is a one-liner. Now inlined asxcode-selectagainst the highest-versioned non-beta/Applications/Xcode_*.app..github/dependabot.ymlso the pins don't silently rot — it bumps the SHA and the comment together, grouped into one weekly PR.sha_pinning_requiredis now enabled on the repo, so any branch still carrying tag-pinneduses:lines will fail until rebased past this.The
select latest stable Xcodeandtoolchain versionssteps in the mac job are the ones to check — they exercise the replacement.