[security-audit] FAIL on 2026-07-20

[github-actions]

Audit failed at 2026-07-20T07:35Z. Run

Security Audit Report

Audited against SECURITY.md as of commit 5b42136 (2026-07-20). $AUDIT_PAT (fine-grained,
read-only Administration + Secrets + Environments) was available and used for all admin-scoped
checks below.

FAIL IF results

Dependency Supply Chain

1. PASS — Ran node website/scripts/generate-deps.js from a clean checkout (git status was
   clean before and after). git diff --stat against website/src/data/dependencies-{npm,cargo,runtime}.json
   produced no output — no drift.
2. PASS — package.json:6-12 has devEngines.runtime.version: "24.18.0" — exact MAJOR.MINOR.PATCH.
3. PASS — standalone/src-tauri/build.rs:42-43,149-227 (read_pinned_node_version +
   verify_node_version) reads devEngines.runtime.version and fails the build (Err(...)) if the
   bundled binary's node --version doesn't match.
4. PASS — .github/workflows/release.yml:39-41 (build-standalone job):
   actions/setup-node@... with node-version-file: package.json, which resolves
   devEngines.runtime.version.
5. PASS — pnpm-workspace.yaml:23 has minimumReleaseAge: 1440.
6. PASS — .github/renovate.json:3 — enabledManagers: ["github-actions", "npm", "cargo"].
7. PASS — .github/renovate.json:68-82 — minimumReleaseAge package rules for npm/cargo at
   patch (1 day), minor (3 days), major (14 days).

GitHub Actions Policies

8. PASS — grep -rn pull_request_target .github/workflows matched only
   .github/workflows/tend-review.yaml:11.
9. PASS — Non-agent-managed workflows (ci.yml, chromatic.yml, release.yml) checked:
   • ci.yml:8-9, chromatic.yml:13-14: contents: read only, no writes.
   • release.yml build-standalone/build-vscode jobs (lines 14-17, 162-165):
     contents: read, id-token: write, attestations: write — exactly the allowed release
     provenance set.
   • release.yml security-audit job (lines 230-239): contents: read, actions: write — the
     explicitly documented exception.
   • release.yml publish-vscode job: no job-level permissions: block, inherits the workflow's
     top-level contents: read (no write).

Automated Maintainer (tend)

10. PASS — Ruleset Merge access (id 16757376, GH_TOKEN=$AUDIT_PAT gh api repos/diffplug/dormouse/rulesets/16757376): target: branch, conditions.ref_name.include: ["~DEFAULT_BRANCH"], rules: [{"type":"update"}], bypass_actors: [{"actor_id":5, "actor_type":"RepositoryRole","bypass_mode":"exempt"}] — sole bypass actor is admin (role id 5).
11. PASS — Ruleset Tag operations (id 16757382): target: tag, conditions.ref_name.include: ["~ALL"], rules: [{"type":"creation"},{"type":"update"}], same sole admin-only bypass actor.
12. PASS — GH_TOKEN=$AUDIT_PAT gh api repos/diffplug/dormouse/collaborators/dormouse-bot/permission
    → {"permission":"write","role_name":"write"} — exactly push/write, not higher.
13. PASS — GH_TOKEN=$AUDIT_PAT gh api repos/diffplug/dormouse/actions/secrets → repo-level
    secrets are CHROMATIC_PROJECT_TOKEN, CLAUDE_CODE_OAUTH_TOKEN, TEND_BOT_TOKEN only. Neither
    OVSX_PAT nor VSCE_PAT present at repo level.
14. PASS — Environments (gh api repos/diffplug/dormouse/environments): only security-audit
    and vscode-extension-publish exist.
    • security-audit deployment-branch-policies: main (branch) + v* (tag) — both admin-gated
      (Merge access / Tag operations).
    • vscode-extension-publish deployment-branch-policies: v* (tag) only — admin-gated
      (Tag operations).
15. PASS — AUDIT_PAT is present in the security-audit environment secrets
    (gh api .../environments/security-audit/secrets → {"total_count":1,"secrets":[{"name":"AUDIT_PAT",...}]})
    and absent from the repo-level secret list (check 13's output).
16. PASS — .config/tend.yaml:4-5 — secrets.allowed: [CHROMATIC_PROJECT_TOKEN].
17. PASS — .github/workflows/workflow-audit.yaml exists, is not disabled (on: schedule +
    workflow_dispatch), and its most recent run
    (gh api repos/diffplug/dormouse/actions/workflows/workflow-audit.yaml/runs) completed
    success at 2026-07-19T09:13:32Z, ~22h before this audit (date -u → 2026-07-20T07:32:25Z),
    well inside 48h.
18. PASS — All tend-*.yaml action refs are tag-pinned (actions/checkout@v7,
    max-sixty/tend/claude@0.1.11) — none use @main or an unpinned ref. Tag pins are explicitly
    accepted in this file class.
19. FAIL — .github/workflows/tend-mention.yaml's verify job (lines 34-205) declares no
    permissions: block (only the handle job, line 213, has one; grep confirms no top-level
    permissions: key exists in the file either). The repo's default Actions token permission is
    write (GH_TOKEN=$AUDIT_PAT gh api repos/diffplug/dormouse/actions/permissions/workflow →
    {"default_workflow_permissions":"write","can_approve_pull_request_reviews":true}). That default
    grants the job's ambient GITHUB_TOKEN write access to every scope (contents, issues,
    pull-requests, actions, checks, deployments, packages, security-events, statuses, …), which
    exceeds the allowed set (contents: write, pull-requests: write, issues: write,
    id-token: write, actions: read, or any read). See Qualitative findings for exploitability
    discussion.

VS Code Extension Releases

20. PASS — release.yml:294-296 — publish-vscode job has environment: {name: vscode-extension-publish}.
21. PASS — grep -rn 'VSCE_PAT|OVSX_PAT' .github/workflows matched only
    release.yml:325,337, both inside the publish-vscode job (the only job with the
    vscode-extension-publish environment).
22. PASS — No production desktop signing secret names (APPLE_SIGN_PASS, EV_SIGN_PIN,
    TAURI_SIGNING_PRIVATE_KEY from a repo/org secret) appear in release.yml; grep -n 'secrets\.' release.yml returns only GITHUB_TOKEN, VSCE_PAT, OVSX_PAT.
23. PASS — release.yml:63-74 ("Generate ephemeral Tauri updater key") runs tauri signer generate --ci --write-keys ... --force for every CI build; no persistent/production updater key
    is injected.

Desktop Releases

24. PASS — scripts/sign-and-deploy.sh:392-399 (verify_downloaded_artifact) calls gh attestation verify with --cert-identity/--cert-oidc-issuer/--source-ref/--source-digest
    before any signing proceeds.
25. PASS — scripts/sign-and-deploy.sh:401-403 calls check_sha256_manifest (sha256sum -c /
    shasum -a 256 -c) after attestation verification.
26. PASS — scripts/sign-and-deploy.sh:683-718 (sign_windows) uses jsign --storetype PIV.

CI Validation Contract

27. PASS — .github/workflows/security-audit.yaml exists, is enabled (schedule +
    workflow_dispatch), and release.yml's publish-vscode job has needs: [..., security-audit]
    (line 290-293), with the security-audit job (227-286) dispatching and gating on this workflow.
28. PASS — security-audit.yaml still requires the qualitative pass (prompt lines 90-93),
    treats the FAIL IF list as non-exhaustive (lines 83-85), keeps the failure-reporting step that
    opens/updates a security-audit-failure issue and exits non-zero (lines 123-172), and keeps the
    AUDIT_PAT pre-check that fails the job if the secret is absent (lines 47-55).

Qualitative findings

• BLOCKER — .github/workflows/tend-mention.yaml, verify job (no permissions: block,
  lines 34-205). This job runs on issues (edited), issue_comment (created/edited),
  pull_request_review (submitted), and pull_request_review_comment (edited) — all
  attacker-influenceable triggers per SECURITY.md's own "Prompt-injection through user-supplied
  content" threat model. Because the repo's default_workflow_permissions is write, this job's
  ambient GITHUB_TOKEN carries full write scope across contents/issues/PRs/actions/checks/
  deployments/packages/security-events/statuses. In the current file, every authenticated step in
  this job explicitly overrides GITHUB_TOKEN with secrets.TEND_BOT_TOKEN for its own gh calls,
  so the ambient token is not consumed today — but it still exists as a live, over-scoped credential
  in the runner for the job's duration, contradicts the least-privilege pattern every sibling job in
  this repo follows (all other jobs, including handle in the same file, declare an explicit
  permissions: block), and would silently regrant broad write access to any future step added to
  this job (or to any action/dependency it pulls in) without anyone touching a permissions: line.
  Fix: add an explicit permissions: {contents: read} (or the minimal read set the job actually
  needs) to the verify job, matching the pattern used everywhere else in this repo. Note this file
  is machine-generated by tend (# Do not edit this file directly); the fix belongs upstream in
  the tend-ci-runner plugin's job template, or the regeneration needs a local override mechanism.
• INFO — .github/workflows/chromatic.yml:39 pins chromaui/action by full commit SHA
  (94713c544284a14195de3b50ef24301579f1877e) but trails it with a stale # latest comment instead
  of a version number. Not a security issue (the ref is a real SHA pin, satisfying the "pinned by
  commit hash" rule) — just a misleading comment for future readers/Renovate diffs.
• INFO — Reviewed all run: steps across every workflow for classic GitHub Actions script
  injection (untrusted ${{ github.event.* }} interpolated directly into a shell string). Found
  none: tend-mention.yaml and all other workflows correctly route event-derived strings (comment
  bodies, issue titles, URLs) through env: maps and reference them as shell variables
  ($COMMENT_BODY, etc.), which is the safe pattern. No action needed.
• INFO — vscode-extension-publish environment's required_reviewers protection rule lists two
  named human reviewers (nedtwigg, edgartwigg) with prevent_self_review: true, matching
  SECURITY.md's description that the publish approval "can't be the same account which triggered the
  publish." Confirmed via gh api repos/diffplug/dormouse/environments.
• INFO — pnpm-workspace.yaml's allowBuilds disables native postinstall scripts for
  @vscode/vsce-sign and keytar while allowing them for @swc/core, esbuild, node-pty,
  sharp — a deliberate, narrow allowlist consistent with the "small dependency surface" posture in
  SECURITY.md §Dependency Supply Chain. No action needed.

Summary

FAIL. All 23 previously-passing FAIL IF checks that could be mechanically verified with the
provided tokens remain PASS, including every ruleset, environment, secret-placement, and signing
check that requires $AUDIT_PAT. However, one FAIL IF is newly violated: the verify job in
.github/workflows/tend-mention.yaml — a job triggered by attacker-influenceable events (issue and
PR comments) — has no explicit permissions: block, and the repository's default_workflow_permissions
is write, so that job's GITHUB_TOKEN silently carries full write scope across every permission
category instead of the bounded set SECURITY.md requires for agent-managed workflows. No currently-
written step in the job spends that ambient token (all authenticated calls use the separately-scoped
TEND_BOT_TOKEN instead), so there is no active exploit path today, but the drift from the repo's
own declared policy is real, mechanically confirmed, and sits exactly on the threat surface
SECURITY.md calls out for this bot. This alone is sufficient to fail the audit per the "FAIL IF any
FAIL IF is violated" rule in the CI Validation Contract.

[dormouse-bot]

Nightly sweep followed up on this. Two things worth recording:

Regeneration does not fix it. I ran uvx tend@latest init in a clean worktree — latest tend is still 0.1.11, and the regenerated tend-mention.yaml is byte-identical to what's committed. So this isn't local drift; the verify job's missing permissions: block is baked into tend's generator template. Confirmed against tend main: generator/src/tend/templates/mention.yaml.j2 declares permissions: only on the handle job (via the permissions() macro), never on verify. Every other tend template renders a single job, so mention is the one place a job ships with no explicit permissions: block.

No active exploit today, but the fix is a one-liner. Every gh call in the verify job (lines 34–205) — e.g. lines 129, 171, 199 — sets GITHUB_TOKEN: ${{ secrets.TEND_BOT_TOKEN }} in its own env:, so the ambient token is never consumed. But it still sits in the runner as an over-scoped credential for the job's lifetime, since default_workflow_permissions is write. Adding permissions: { contents: read } to the verify job would match every sibling job in this repo and close the drift.

Because the file is machine-generated (# Do not edit this file directly), a local edit would be overwritten on the next regen, and .config/tend.yaml exposes no per-job permissions override. So the durable fix belongs upstream in the template.

@nedtwigg — may I file an issue at max-sixty/tend for this? It's a small generator-template change (add a read-only permissions: block to the verify job in mention.yaml.j2), and I have the evidence above ready to paste. I won't file cross-repo without your go-ahead.

[github-actions]

Audit failed at 2026-07-21T06:51Z. Run

Security Audit Report

Audited against SECURITY.md as of commit 5b42136 (main, shallow checkout).

FAIL IF results

Dependency Supply Chain

1. generate-deps.js diff on clean checkout — PASS. Ran node website/scripts/generate-deps.js from the checked-out tree; git status --porcelain and a byte diff of website/src/data/dependencies-{npm,cargo,runtime}.json before/after showed no changes.
2. devEngines.runtime.version present and exact — PASS. Root package.json: "devEngines": { "runtime": { "name": "node", "version": "24.18.0", ... } } — exact MAJOR.MINOR.PATCH.
3. build.rs verifies bundled Node against the pin — PASS. standalone/src-tauri/build.rs:149-219 (read_pinned_node_version + verify_node_version) reads devEngines.runtime.version from package.json and fails the build (bundled Node.js {actual} does not match ... pin {pinned}) on mismatch.
4. build-standalone installs the pinned runtime via devEngines.runtime.version — PASS. .github/workflows/release.yml:39-41 uses actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 with node-version-file: package.json. Verified against actions/setup-node's own source (src/util.ts:29-33, getNodeVersionFromFile) that it parses devEngines.runtime from a package.json-shaped file — this is a real, not incidental, read of the pin. Same pattern used in ci.yml and security-audit.yaml.
5. pnpm-workspace.yaml has minimumReleaseAge: 1440 — PASS. Present verbatim.
6. .github/renovate.json enabledManagers includes npm and cargo — PASS. "enabledManagers": ["github-actions", "npm", "cargo"].
7. Renovate minimumReleaseAge rules for npm/cargo — PASS. Three packageRules entries scope matchManagers: ["npm","cargo"] to minimumReleaseAge of "1 day" (patch), "3 days" (minor), "14 days" (major).

GitHub Actions Policies

8. pull_request_target only in tend-*.yaml — PASS. grep -rl pull_request_target .github/workflows/ → only tend-review.yaml (single job, contents/pull-requests/id-token/actions/issues perms matching the agent-managed allowance below).
9. No non-agent-managed workflow grants write perms beyond id-token/attestations/the security-audit job's actions: write — PASS. Enumerated every permissions: block in chromatic.yml, ci.yml, release.yml: top-level is contents: read everywhere; build-standalone/build-vscode add only id-token: write + attestations: write; the security-audit job in release.yml (line 230-238) adds only actions: write, matching the documented exception exactly; publish-vscode has no job-level permissions: (inherits contents: read).

Automated Maintainer (tend)

10. Merge access ruleset — PASS. GH_TOKEN=$AUDIT_PAT gh api repos/diffplug/dormouse/rulesets/16757376 → target: branch, conditions.ref_name.include: ["~DEFAULT_BRANCH"], rules: [{"type":"update"}] (only), bypass_actors: [{"actor_id":5,"actor_type":"RepositoryRole","bypass_mode":"exempt"}] (admin only, sole entry).
11. Tag operations ruleset — PASS. .../rulesets/16757382 → target: tag, conditions.ref_name.include: ["~ALL"], rules: [{"type":"creation"},{"type":"update"}] (both present, nothing else), same admin-only sole bypass actor.
12. dormouse-bot permission ≤ push — PASS. GH_TOKEN=$AUDIT_PAT gh api repos/diffplug/dormouse/collaborators/dormouse-bot/permission → "permission":"write" (write = push; admin:false, maintain:false).
13. OVSX_PAT/VSCE_PAT not repo-level — PASS. GH_TOKEN=$AUDIT_PAT gh api repos/diffplug/dormouse/actions/secrets → only CHROMATIC_PROJECT_TOKEN, CLAUDE_CODE_OAUTH_TOKEN, TEND_BOT_TOKEN at repo level. GH_TOKEN=$AUDIT_PAT gh api repos/diffplug/dormouse/environments/vscode-extension-publish/secrets → OVSX_PAT, VSCE_PAT present there only. grep -rn "OVSX_PAT\|VSCE_PAT" .github/ scripts/ shows both used only inside the publish-vscode job, which declares environment: { name: vscode-extension-publish }.
14. Environment deployment-branch-policies admit only admin-gated refs — PASS. vscode-extension-publish: deployment_branch_policy → v* tag only (admin-gated by rule 11). security-audit: → main + v* tag (both admin-gated by rules 10/11).
15. AUDIT_PAT env-scoped, not repo-level — PASS. GH_TOKEN=$AUDIT_PAT gh api repos/diffplug/dormouse/environments/security-audit/secrets → AUDIT_PAT present; absent from the repo-level secret list in check 13. Also spot-verified the PAT's actual scope: it can read rulesets/collaborator-permissions/env-secrets (admin-read) but a write probe (POST .../labels) returned 403 Resource not accessible by personal access token — consistent with "read-only Administration + Secrets + Environments."
16. CHROMATIC_PROJECT_TOKEN in secrets.allowed — PASS. .config/tend.yaml: secrets: { allowed: [CHROMATIC_PROJECT_TOKEN] }.
17. workflow-audit.yaml exists, enabled, successful run in last 48h — PASS. state: "active"; most recent successful run 2026-07-20T10:19:00Z (conclusion success), current time 2026-07-21T06:44:58Z ≈ 20.5h ago.
18. No unpinned action refs in tend-*.yaml — PASS. All uses: lines use version tags (actions/checkout@v7, max-sixty/tend/claude@0.1.11), never @main or bare.
19. Agent-managed workflows (tend-*.yaml, workflow-audit.yaml, security-audit.yaml) stay within the allowed permission set — PASS. All tend-*.yaml jobs: contents: write, pull-requests: write, id-token: write, actions: read, issues: write (subset of allowed). workflow-audit.yaml: contents: read, issues: write, actions: read. security-audit.yaml: contents: read, actions: read, issues: write, id-token: write. All within {contents:write, pull-requests:write, issues:write, id-token:write, actions:read, any read}.

VS Code Extension Releases

20. vscode-extension-publish environment on publish job — PASS. release.yml:295-296, publish-vscode job declares environment: { name: vscode-extension-publish }.
21. VSCE_PAT/OVSX_PAT used only within that environment — PASS (same evidence as check 13).
22. No production desktop signing secrets in CI — PASS. grep -in "TAURI_SIGNING\|MACOS_CERTIFICATE\|CSC_\|APPLE_" .github/workflows/release.yml → only the ephemeral-key step (release.yml:63-74) sets TAURI_SIGNING_PRIVATE_KEY to a freshly generated $RUNNER_TEMP file path; no secrets.* reference for any signing material.
23. Ephemeral Tauri updater key still generated — PASS. release.yml:63-74, pnpm --dir standalone exec tauri signer generate --ci --write-keys "$RUNNER_TEMP/tauri-ci-updater.key" --force, freshly generated every run, never persisted as a secret.

Desktop Releases

24. sign-and-deploy.sh verifies artifact attestations — PASS. verify_downloaded_artifact() (scripts/sign-and-deploy.sh:369-402) calls gh attestation verify with --cert-identity/--cert-oidc-issuer/--source-ref/--source-digest, and verify_downloaded_artifacts is actually invoked from the main flow at lines 472 and 517 (not dead code).
25. sign-and-deploy.sh verifies SHA-256 manifests — PASS. check_sha256_manifest() (line 359) runs sha256sum -c/shasum -a 256 -c against artifact-manifest.sha256, called from the same verify_downloaded_artifact path, plus validate_sha256_manifest_paths guards against absolute/.. paths in the manifest before trusting it.
26. PIV-backed Windows signing — PASS. sign_windows() (line 684) uses jsign --storetype PIV --alias AUTHENTICATION ... for both the inner exe and the installer; no non-PIV/file-based key path present.

CI Validation Contract

27. security-audit.yaml exists, enabled, invoked from release.yml's publish path — PASS. state: "active"; release.yml's security-audit job dispatches it via gh workflow run security-audit.yaml and gates publish-vscode on it (needs: [..., security-audit]).
28. Audit not weakened — PASS. The live security-audit.yaml prompt (lines 82-121) still requires the qualitative pass ("flag any other security hole you find"), forbids treating any FAIL IF as ignorable, retains the failure-reporting step that opens/comments a security-audit-failure-labeled issue and exit 1s (lines 123-172), and retains the AUDIT_PAT pre-check step (lines 47-55) that writes FAIL and exits non-zero if the secret is absent. This is the exact prompt this run executed under.

All 28 FAIL IF checks: PASS.

Qualitative findings

• BLOCKER — Non-constant-time control-token comparison lets a local attacker recover the dor control-socket bearer token via timing side-channel. standalone/sidecar/dor-control-server.js:60: if (request.token !== token) { ... } is a short-circuiting !== string compare, not constant-time. This module is shared verbatim by both hosts (vscode-ext/src/pty-host.js:7,13 and standalone/sidecar/main.js:13,35), so it affects the VS Code extension's pty-host and the standalone Tauri sidecar alike. No socket-level permission hardening (chmod/ACL) exists as a backstop — grep -n "chmod\|0o600\|0o700" across standalone/sidecar/dor-control-server.js, standalone/sidecar/main.js, vscode-ext/src/pty-host.js, vscode-ext/src/pty-manager.ts found nothing; the socket/pipe path (dor_control_socket_path(), lib.rs:1047-1058) is the only gate, and authorization rests entirely on this token comparison. A co-resident local process can byte-by-byte time the response to handleRequest and recover the token even where it has real entropy (VS Code side uses randomBytes(24)), then issue arbitrary dor control requests against the user's live terminal sessions per the Surface handle model in docs/specs/dor-cli.md.
• BLOCKER — Standalone desktop app's dor control token is generated from PID + timestamp, not a CSPRNG. standalone/src-tauri/src/lib.rs:1062-1068 (dor_control_token): format!("{}-{nanos}", std::process::id()). std::process::id() is trivially discoverable locally (ps/tasklist), and the nanosecond timestamp's effective entropy collapses to whatever window an attacker can bound the app's launch time to. Contrast with vscode-ext/src/pty-manager.ts:116: randomBytes(24).toString('hex'), which is correct. The standalone app is the primary shipped desktop product per docs/specs/standalone.md, and combined with the timing side-channel above, a co-resident local attacker has a materially tractable path to hijacking the app's terminal control channel — this is exactly the class of local-trust boundary SECURITY.md's opening paragraph calls out ("users trust it with shells, source trees, credentials, and local files").
• WARNING — Selfhost server state files (hosts.json, account.json) are written world-readable, exposing the host relay bearer token in plaintext on shared machines. server/src/state.ts:79-84 (writeAtomic): mkdir(stateDir, { recursive: true }) and writeFile(tmp, ..., 'utf8') both omit an explicit mode, so they inherit the process umask (typically yielding 0644/0755 on Linux). hosts.json stores hostToken (the WS bearer secret for the host↔server relay, state.ts:140-146) in plaintext. On a multi-user machine running the selfhost server, any other local account can read active host tokens. Downstream handling is otherwise sound: findByToken compares via timingSafeEqual over SHA-256 digests (state.ts:170-178), and the HTTP layer never re-exposes hostToken after the one-time enrollment response (server/src/app.ts:347 returns it once; the /hosts list route omits it, app.ts:390-398). Recommend writeFile(tmp, ..., { mode: 0o600 }) and mkdir(stateDir, { recursive: true, mode: 0o700 }).
• INFO — VS Code extension's CSP nonce uses Math.random() instead of a CSPRNG. vscode-ext/src/webview-html.ts:62-68 (getNonce) builds the script-src 'nonce-...' value (used at lines 22, 29, 49-56) from Math.random() over a 62-character alphabet, 32 characters long. This is the same pattern as Microsoft's own vscode-extension-samples reference code, and the webview HTML is generated entirely by the extension (not attacker-network-controlled), so practical exploitability is low — but it deviates from the CSP nonce threat model (unpredictability), and node:crypto's randomBytes is already a dependency of this codebase (used correctly elsewhere, e.g. pty-manager.ts:116), so fixing it costs nothing.
• INFO — Server-side secret comparisons and crypto primitives are otherwise sound. Spot-checked server-lib-common/src/security/: bytes.ts constantTimeEqual is a proper non-short-circuiting XOR-accumulate compare; passkey.ts verifies WebAuthn assertions (challenge/origin/rpId/flags/signature) via WebCrypto subtle.verify, no home-rolled signature logic; no Math.random() usage anywhere in that directory. No hardcoded credentials or private-key material found repo-wide (grep for AWS keys, PEM headers, GitHub PAT patterns — no hits), no tracked .env files, and .gitignore correctly excludes .env.local and the local release-signed/ signing workdir.

Summary

Overall: FAIL.

Every mechanical FAIL IF check in SECURITY.md passes — the CI/CD supply chain, ruleset, environment, secret-scoping, and release-signing controls the spec describes are all implemented as documented, with no drift found. However, the qualitative pass (which the spec itself requires as part of a complete audit) surfaced two BLOCKER-severity findings in the dor local control-socket protocol shared by the standalone desktop app and the VS Code extension: a non-constant-time token comparison (standalone/sidecar/dor-control-server.js:60) and, on the standalone app specifically, a predictable PID+timestamp token instead of a CSPRNG (standalone/src-tauri/src/lib.rs:1062-1068). Together these give a co-resident local attacker a realistic path to recovering the control token and issuing arbitrary commands against a user's live terminal sessions — squarely the kind of local-trust-boundary compromise SECURITY.md's own threat model (shells, source trees, credentials, local files) is meant to guard against, even though the document's FAIL IF list doesn't enumerate this specific surface. A WARNING-level plaintext-credential-file-permissions gap in the selfhost server (server/src/state.ts:79-84) and an INFO-level weak-nonce nit in the VS Code webview round out the findings.

[dormouse-bot]

I verified both BLOCKER findings against the code and opened #282 to fix them:

• Non-constant-time token compare — dor-control-server.js:60 used a short-circuiting !==. fix(dor): harden control-socket token against local attackers #282 hashes both sides to SHA-256 digests and compares via timingSafeEqual (same pattern server/src/state.ts already uses). Since the module is shared by both hosts, this fixes the VS Code pty-host and the standalone sidecar together.
• Predictable standalone token — lib.rs:1062 derived the token from PID + timestamp. fix(dor): harden control-socket token against local attackers #282 draws 24 bytes from the OS CSPRNG (getrandom, already in the lock tree) and hex-encodes, matching the VS Code host's randomBytes(24).

The two lower-severity findings are not in #282, to keep it atomic — they touch separate subsystems and can follow up:

• WARNING — world-readable selfhost state files leaking hostToken (server/src/state.ts:79-84): add { mode: 0o600 } / { mode: 0o700 } to the writeFile/mkdir.
• INFO — Math.random() CSP nonce in the VS Code webview (vscode-ext/src/webview-html.ts:62-68): swap to randomBytes, already a dependency.

A maintainer should review #282 before merge; happy to open follow-ups for the WARNING/INFO on request.