Repository navigation
main is red: actions.lock omits a transitive dependency of asana/push-signed-commits (actions/setup-python@v2) #963
Description
Summary
main is red. scan / Hypatia Neurosymbolic Analysis and governance / Validate Hypatia Baseline
both fail at 9c256b67 (#954), on one high-severity finding that survives the baseline.
The finding
{
"type": "invalid_actions_lock",
"rule_module": "workflow_hardening",
"file": ".github/workflows/actions.lock",
"severity": "high",
"action": "regenerate",
"baseline_status": "new",
"reason": "actions.lock failed closed: {:transitive_dependencies_missing,
[{\"asana/push-signed-commits@d615ca88d8e1a946734c24970d1e7a6c56f34897\",
\"actions/setup-python@v2\"}]}"
}asana/push-signed-commits@d615ca88 itself depends on actions/setup-python@v2, and the lockfile
records no entry for that transitive dependency. Hypatia fails closed on it, which is the
correct behaviour — this is a real gap, not a scanner defect.
When it started
failure 2026-09-22T10:15:10Z 9c256b67 <- #954
success 2026-09-22T10:10:08Z be6c9580
success 2026-09-22T09:59:46Z e977cc67
success 2026-09-22T09:56:48Z 7b05a323
failure 2026-09-22T09:46:37Z a2ff696a
#954 is titled "asana restore+ack, …". The restore of the asana step is what introduced the
unrecorded transitive dependency.
Note that governance / Actions lockfile verify and uses ⊆ actions.lock are green at the same
commit. They check the workflows' own uses: refs against the lock; Hypatia additionally resolves
each locked action's own dependencies. The two controls ask different questions, and only
Hypatia asks this one.
Acceptance criteria
.github/workflows/actions.lockrecordsactions/setup-pythonas a transitive dependency of
asana/push-signed-commits@d615ca88d8e1a946734c24970d1e7a6c56f34897, SHA-pinned, or the
asana step is removed / replaced with an action whose dependencies are lockable.actions/setup-python@v2is not adopted at a floating major tag — if it is recorded, it is
recorded at a 40-hex commit, consistent with the rest of the lock.scan / Hypatia Neurosymbolic Analysisandgovernance / Validate Hypatia Baselineare green on
main, withfindings_keptempty.- The fix is not a baseline entry.
baseline_status: "new"withaction: "regenerate"is the
scanner telling us the lock is wrong, not that the rule is wrong; baselining it would be muting a
correct diagnostic. - A regression control exists that fails if a locked action's transitive dependency goes
unrecorded again — or, if Hypatia is judged to be the only reasonable place for that check, this
issue records that decision explicitly.
Not a blocker on
#962, which inherits both reds from this commit and touches neither
actions.lock nor any uses: ref.
🤖 Generated with Claude Code
Activity
fix(baseline): repoint the lock ack at its live tracking issue
fix(P0): Execute owner decisions from investigation
ci(lock): drop orphan asana/setup-python records from actions.lock (#…
hyperpolymath commentedon Oct 14, 2026
Cure landed
The defect is gone from
main. Two PRs fixed it:asana/push-signed-commitsin.github/actions/signed-push/withpush-verified.sh(bash +gh+jq,createCommitOnBranch).asana/push-signed-commits@d615…and theactions/setup-python@v2records from.github/workflows/actions.lock. Every lock key and nesteduses:ref is now a 40-hex SHA.The Hypatia scan on
mainat7d2041a(run 38484072239, scanner51ab6496) reports 59 findings:findings_keptis[];invalid_actions_lock;actions.lock, asana or setup-python.The
**actions.lockacknowledgement was therefore matching nothing. #1239 removes it.Acceptance criteria
Met. The Asana step was replaced (feat(k9): vnd.k9.coordination subtype, coordination grammar v1.2.0, native signed-push #1233) and its lock records were removed (ci(lock): drop orphan asana/setup-python records from actions.lock #1238).
Met.
actions/setup-python@v2is no longer in the lock at any ref.Met on
main. The scan is green withfindings_keptempty.Met when ci(hypatia): retire the cured invalid_actions_lock ack (#963) #1239 merges. Until then the baseline entry still exists. It suppresses nothing today, but its
**actions.lockpattern would mute any newinvalid_actions_lockuntil 2026-12-22.What exists now; the decision itself is yours. Hypatia is still the only control that resolves a locked action's own dependencies.
Actions lockfile verifyanduses ⊆ actions.lockdon't, and gh-actions-lock v0.1.6 passed the Asana record. With the ack removed:mainon a recurrence. A localapply-baseline.shrun on both emission paths gives kept=2, exit 1.scripts/tests/apply-baseline-test.shnow asserts that the shipped ledger holds noinvalid_actions_lockack, so restoring one reds the suite.Whether Hypatia should stay the only place for this check is your call to record here. I haven't decided it on your behalf.
#1239 carries
Closes #963, so this issue closes when #1239 merges.Generated by Claude Code