Repository navigation
Pin sigstore/cosign-installer instead of tracking @main (all 15 operators) #18
Description
Activity
PRs opened across all 15 repositories — one line each,
@main→@v4:Repo PR commons-operator #302 listener-operator #342 secret-operator #367 zookeeper-operator #373 airflow-operator #196 doris-operator #112 spark-k8s-operator #280 superset-operator #277 hdfs-operator #325 hive-operator #351 kafka-operator #304 nifi-operator #98 hbase-operator #266 trino-operator #388 dolphinscheduler-operator #266 Each diff is a single line in
.github/workflows/release.yml; workflow YAML validated in every repo.cosign-installerappears only inrelease.yml— no other workflow references it.Not covered by these PRs, worth deciding separately: adding
sigstore/cosign-installerto dependabot so future major versions arrive as reviewable PRs rather than needing another sweep.Correction to my last comment — the dependabot suggestion is unnecessary, and the reason is itself the missing piece of this story.
All 15 repos already have
package-ecosystem: "github-actions"configured on a weekly schedule:- package-ecosystem: "github-actions" directory: "/" schedule: interval: "weekly"
So why did dependabot never flag
cosign-installer? Because@mainis a branch reference, not a version — there is nothing for dependabot to bump. It silently skipped this action while dutifully keeping the other ten current. That is exactly why this one drifted alone.Pinning to
@v4brings it back under dependabot's coverage automatically. No config change needed; future major versions will arrive as reviewable PRs on their own.Which also makes the general lesson sharper than "pin your actions": an unpinned action is invisible to the tooling that would otherwise keep it honest. The gap was not that nobody was watching — it was that the watcher had nothing to watch.
Done — all 15 PRs merged and verified on
main:sigstore/cosign-installer@v4in everyrelease.yml(15/15)github-actionsecosystem present in everydependabot.yml(15/15)
The second item was not in the original scope. spark-k8s-operator turned out to be the only repo without
package-ecosystem: "github-actions"— configured forgomodanddockeronly. That explains an anomaly noticed earlier in the 0.4.0 work: itsgolangci-lint-actionsat onv7/v8while every other repo had moved tov9. Nothing was proposing the bumps. Added alongside the pin, since pinning only helps if something keeps it current.Closing.
What
Every operator's release workflow tracks the action's default branch:
All 15 repositories. It is the only unpinned action in these workflows —
every other one is pinned to a release:
Why it matters — a concrete example
The signature storage format changed underneath the release process without
anyone noticing.
Older cosign published signatures as a separate
sha256-<digest>.sigtag.Current cosign attaches them as OCI referrers instead:
commons-operator's registry still shows nine
.sigtags, the newest dated2025-10-06. That date is not when signing stopped — it is when the tooling
silently switched schemes, because
@mainpicked up a new major version betweenreleases.
Signing works correctly today; all 15
0.4.0images passcosign verify. Butthe behaviour change was invisible until someone went looking, and it did briefly
lead to a false "signatures are missing" report during 0.4.0 verification.
The general risk: an unpinned action in a release path means a third party's
merge to
maincan alter what a tagged, signed release produces — with no diffin this org to review, and no way to reproduce an old release's exact behaviour.
Suggested change
Pin like everything else. Latest release is
v4.1.2(2026-05-07):Worth applying across all 15 repos in one pass, alongside dependabot coverage so
upgrades arrive as reviewable PRs rather than silently.
Context
Found while verifying 0.4.0 release artifacts. Not a defect in the current
release — the images are signed and verify correctly.
🤖 Generated with Claude Code