[Jaro-c]

Enforces the rule added to standards/ci in Glyndor/ai-context#125. Acts on Glyndor/apt#121.

The rule

A job that installs third-party tooling must not hold a secret. cargo install executes build.rs for every crate it resolves; go install, gem install and an unpinned pip install are the same shape.

pip install --require-hashes is exempt — it fixes the exact artifacts, so nothing is resolved. cargo install --locked is not: it pins the tool's version and then builds the tool's own tree.

What it actually defends against

Worth stating precisely, because the obvious framing is wrong and I reached for it first. Secrets are injected per step, not per job — a job with no env: block does not place ${{ secrets.X }} in the environment of a step that does not name it. So a build script at an install step cannot read a key that a later step declares.

What it can do is persist: alter a script or a requirements file in the workspace that the signing step then executes with the key in its environment. Splitting the job removes the shared workspace, and that is the part that carries. The comment above the step says this, so nobody applies the rule to the wrong threat.

Why it lives here

workflow-lint is the reusable that already runs actionlint over the caller's workflows, so the caller is checked out and every consumer gets the rule without per-repo work.

Not breaking anyone today

Gated behind tooling-isolation, type: boolean, default: true — the same shape as check-exec-bit in shell-ci.yml. Three repositories do not meet it: epistle (1), helmly (2), helmly-agent (2). They meet it when they next bump their pin deliberately, which is this organisation's pattern for a new check rather than an accident.

Verified by running it

Against every cloned repository in the organisation:

github-config podup apt homebrew-tap scoop-bucket   exit=0
epistle-panel klyradb unitpm authcore specio        exit=0
epistle                                             exit=1   1 violation
helmly · helmly-agent                               exit=1   2 each

Those findings match, one for one, an independent sweep run before this check existed — same files, same jobs, same lines. Two instruments agreeing is worth more than either alone.

Also exercised on a fixture covering the three edge cases, since a check nobody has watched fail is not a check:

fixture	expected	result
secret + pip install --require-hashes	pass	exit 0
secret + pip install cryptography	fail	exit 1, annotated
cargo install with no secret	pass	exit 0

The annotation says what to do, not only what is wrong:

job build installs third-party tooling while holding a secret: cargo install cross --locked — see Glyndor/apt#121. Fix by moving the install into a job that holds no secrets, or pin it by hash.

actionlint clean. Reusable docs regenerated.

One implementation note

The script is a heredoc rather than python3 -c. Inside a YAML run: | block, YAML strips the block indentation before bash sees it, so an opener and terminator at the same indentation both arrive at column 0 and the heredoc closes correctly — I verified that specifically, having previously mis-diagnosed the opposite. Multi-line python3 -c would have been the actual trap: automatic dedent of -c source arrived in CPython 3.13 and the runner ships 3.12.