What
The Generate SLSA Provenance step in release.yml (Build & Release WASM Component job) intermittently fails at the cosign attest ... --type slsaprovenance call with:
```
Error: signing ghcr.io/pulseengine/wsc@sha256:...: GET https://ghcr.io/token?scope=repository:pulseengine/wsc:pull&service=ghcr.io: DENIED: denied
```
Evidence it's not a one-off coin flip
On 2026-08-07 during the v0.10.0 release, two independent Release runs failed at the same step within the same minute — the tag-push run (id 31188410056) and the main-push run (id 31188386348), both at 14:35–14:36. Correlated simultaneous failure at the same registry call points to a brief ghcr-side outage / rate-limit window, not two independent transients. Both succeeded on re-run with no code change, producing real signed provenance — so v0.10.0 is valid — but the failure mode will recur.
Notably, crane digest and cosign sign on the same image succeeded earlier in the same job — only the subsequent cosign attest token request was denied. So it's a transient token/rate issue on the attest call, not a persistent permissions problem.
Risk
This is the same shape as the crates.io publish that silently failed on four consecutive tags (#220): a release step that needs an occasional manual re-run reads as "release failed" and gets re-run without recording why — or someone ships skipping it.
Proposed fix (own verification)
Wrap the cosign attest calls in a retry-with-backoff (e.g. 3 attempts, exponential) so a brief ghcr token denial self-heals instead of failing the run. This is a release.yml change and should land with its own verification (a release dry-run), not folded into an unrelated release.
What
The
Generate SLSA Provenancestep inrelease.yml(Build & Release WASM Componentjob) intermittently fails at thecosign attest ... --type slsaprovenancecall with:```
Error: signing ghcr.io/pulseengine/wsc@sha256:...: GET https://ghcr.io/token?scope=repository:pulseengine/wsc:pull&service=ghcr.io: DENIED: denied
```
Evidence it's not a one-off coin flip
On 2026-08-07 during the v0.10.0 release, two independent Release runs failed at the same step within the same minute — the tag-push run (id 31188410056) and the main-push run (id 31188386348), both at 14:35–14:36. Correlated simultaneous failure at the same registry call points to a brief ghcr-side outage / rate-limit window, not two independent transients. Both succeeded on re-run with no code change, producing real signed provenance — so v0.10.0 is valid — but the failure mode will recur.
Notably,
crane digestandcosign signon the same image succeeded earlier in the same job — only the subsequentcosign attesttoken request was denied. So it's a transient token/rate issue on the attest call, not a persistent permissions problem.Risk
This is the same shape as the crates.io publish that silently failed on four consecutive tags (#220): a release step that needs an occasional manual re-run reads as "release failed" and gets re-run without recording why — or someone ships skipping it.
Proposed fix (own verification)
Wrap the
cosign attestcalls in a retry-with-backoff (e.g. 3 attempts, exponential) so a brief ghcr token denial self-heals instead of failing the run. This is arelease.ymlchange and should land with its own verification (a release dry-run), not folded into an unrelated release.