tend check: configuration drift on diffplug/dormouse

[dormouse-bot]

tend check reports one FAIL on diffplug/dormouse. It needs repository-admin access, which the CI bot does not hold.

• immutable-releases (FAIL): the newest release (v1.1.0) can be rewritten — a write-access account or bot can replace its assets. gh api repos/diffplug/dormouse --jq .immutable_releases returns null, so the setting has never been enabled. Fix is tend check --fix run by an admin (or Settings → General → "Immutable releases"). GitHub applies the setting only to releases published after it is enabled, so enabling it clears this check at the next release rather than retroactively for v1.1.0.

Every other check passes: branch-protection:main, bot-permission, tag-protection, environment, environment-deployments, credential-environments, secrets, claude-auth, repo-secret-allowlist. The credential-environments FAIL tracked in #339 is cleared.

Why this is not already covered by the release pipeline

.github/workflows/release.yml attests build provenance for the standalone and VS Code artifacts, which lets a consumer detect a substituted asset. Immutable releases is the complementary control: it stops the substitution at the API, so the attestation is not the only thing standing between a compromised write-access token and a rewritten v1.1.0 download. Tag rewriting is already blocked by the Tag operations ruleset (creation + update across ~ALL, bot bypass never); release assets are the remaining mutable surface on a published release.

docs/specs/security-ci.md does not currently mention the setting. Worth adding a row there once it is enabled, so the guarantee is stated where the audit reads it.

Last refreshed: 2026-09-19

[dormouse-bot]

Confirmed against the live repo and not bot-fixable: repos/diffplug/dormouse still returns no immutable_releases field, v1.1.0 reports "immutable": false, and this bot's permissions are {admin: false, maintain: false, push: true}. No code change in this repo clears the check — it is the admin toggle or nothing.

One interaction worth settling before flipping it, which the body doesn't cover: enabling immutable releases retires the retry branch of the desktop release script. create_release() in scripts/sign-and-deploy.sh has two paths — a first-time gh release create with all three assets (line 951), and an "already exists" path that calls gh release upload --clobber and gh release edit --draft=false against the existing release (lines 940–948). Replacing assets on a published release is precisely the operation the setting blocks, so the second path stops working once the setting is on.

That path is not incidental. docs/specs/deploy.md builds the pipeline around re-running stages, and sign-and-deploy.sh --help lists release VERSION ("Re-create GitHub Release from existing signed assets") and resume VERSION as supported entry points — both land in create_release(), and both hit the existing-release branch on a second run. Today a half-finished upload (one platform's asset missing, a bad notarization caught after publish) is repaired by re-running; after enabling, it would not be.

This is a sequencing question, not a blocker. The fresh-create path is unaffected, and the setting only binds releases published after it is enabled, so v1.1.0 stays mutable either way and nothing breaks retroactively. But the first release published under the setting is the one that discovers this, mid-release, with the signing hardware already out.

I did not change the script. The obvious shape — create as a draft, upload assets, then flip --draft=false as the last step, so the release only becomes immutable once its assets are final — reorders a manual pipeline that needs a YubiKey and live Apple credentials to exercise, and I can't run it end to end from CI. Whether to restructure it first or enable and accept a one-shot upload is a call for whoever owns the release runbook.

Verification

$ gh api repos/diffplug/dormouse --jq '.immutable_releases'
(no output — field absent)

$ gh api repos/diffplug/dormouse/releases --jq '.[0] | {tag_name, immutable, published_at}'
{"immutable":false,"published_at":"2026-07-16T17:55:13Z","tag_name":"v1.1.0"}

$ gh api repos/diffplug/dormouse --jq '.permissions'
{"admin":false,"maintain":false,"pull":true,"push":true,"triage":true}

The release assets are exactly three files (FNAME_MAC / FNAME_WIN / FNAME_LINUX, scripts/sign-and-deploy.sh:51-53); the updater manifest is served from website/public/standalone-latest.json, not as a release asset, so it is outside the setting's reach.

On the spec row the body proposes for docs/specs/security-ci.md: leaving it until the setting is enabled is right — above the fold the spec states what the configuration is, and the file already sits at its 2700-word budget in scripts/spec-word-budgets.json (node scripts/spec-lint.mjs --ratchet docs/specs/security-ci.md re-derives the same 2700), so any added row trips the budget and arrives with a --ratchet in the same PR.