Hold the Certum signing jobs to one login at a time

[FrodeHus]

The v1.8.0 release failed on Open the SimplySign session:

SimplySign rejected the credentials 3 times; check the account name, the otpauth URI and the clock.

All three were fine. In the same run, the CLI's Windows job opened a session against the same account and signed successfully.

What actually happened

Four jobs across three workflows sign with one Certum SimplySign account. Two of them — Windows app and the CLI matrix's windows leg — both hang off needs: check, so they start together and log in together. A TOTP code is single-use, so whichever login lands second is told "invalid user name or token". Connect-SimplySign.ps1 can only see an unexpected window: it dismisses it, pastes a fresh code, and after three rounds gives up blaming the credentials.

The race has been there since signing landed in #165. It had simply been winning:

release	Windows app login	CLI (windows) login	overlap
v1.7.0 (worked)	10:31:18 → 10:32:12	10:32:09 → 10:34:16	3 seconds
v1.8.0 (failed)	12:35:46 → 12:38:06	12:36:28 → 12:38:42	the whole time

The fix

A shared certum-simplysign concurrency group holds every signing job in the repository to one login at a time — both release workflows and the manual signing check — with cancel-in-progress: false so the loser queues instead of dying. The queue holds up to 100, so nothing is dropped.

The group cannot be narrowed to the windows leg: job-level concurrency may use only the github, inputs and vars contexts, not matrix. So the CLI's linux and macOS legs queue on it too — minutes of waiting, weighed against an account lockout. Splitting the windows leg into its own job would avoid that, at the cost of duplicating the CLI build steps; worth doing if the wait becomes annoying.

The thrown message now names a concurrent signing job as the first thing to suspect, since the old wording sent this investigation after three things that were all correct.

Verification

Not run end to end: exercising it means a real release, and every attempt is a login against an account that locks on repeated failure. What was checked:

• All four workflows parse, and each signing job carries the group (release.yml × 2, release-audit.yml, signing-check.yml).
• Connect-SimplySign.ps1 parses — the first draft of the message used \" and would have thrown at the exact moment it was needed. PowerShell escapes with a backtick.
• No changelog entry: the gate fires only for macos/, windows/, cli/, shared/ and audit/, and this is release plumbing.

v1.8.0 itself was unblocked separately by re-running the failed job alone, with nothing competing for the session.

Co-authored-by: Claude Opus 5 noreply@anthropic.com

---

Second fault: the release notes step never parsed

With the session fixed, Publish release failed too — a different bug, found the same evening:

line 48: syntax error near unexpected token `)'

Microsoft's sits inside a single-quoted bash string in the Release notes step, so the apostrophe closed the string and left the rest of the sentence bare; the first unquoted ) ended the step. Reproduced locally by extracting the block and running bash -n on it.

v1.8.0 is the first release to reach that line: it landed in #170 at 14:01 on 2026-09-15, and the last release before it ran at 11:20 that morning. release-audit.yml carries the same sentence, so elevate-audit would have failed identically on its next tag. Both are fixed.

Neither notes step runs outside a release, which is how a syntax error sat in main for four days. I checked the rest: every non-pwsh run: block in the repository — 91 of them — now passes bash -n, and only these two were broken. A CI job doing exactly that would be cheap insurance; say the word and I'll add one, though actionlint may be the better tool and will likely surface unrelated warnings.

Note on releasing v1.8.0

Re-running the existing run will not pick this up: a re-run uses the workflow as of the tagged commit. To release 1.8.0 with the fix, merge this, then move the v1.8.0 tag to the new main head and push it — that starts a fresh run on the fixed workflow. The tag is public but no release was ever published against it.