Supply-chain hardening: version pinning, SLSA attestations, fix #506#512
Merged
backnotprop merged 24 commits intomainfrom Apr 8, 2026
Merged
Supply-chain hardening: version pinning, SLSA attestations, fix #506#512backnotprop merged 24 commits intomainfrom
backnotprop merged 24 commits intomainfrom
Conversation
…ndows (#506) Closes #507 items 1-2 and fixes #506. Issue #507 asked for version-pinned installs from a trusted source, immutable releases, and build-provenance attestations. This commit ships: - `--version v0.X.Y` / positional / `-Version` flag across all three installers (bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays `latest` — every existing `curl | bash` / `irm | iex` invocation works unchanged. install.cmd gained `--version` as an alias to its existing positional form for surface-area consistency. - SLSA build provenance attestations via `actions/attest-build-provenance` (SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries (5 plannotator + 5 paste-service). Top-level workflow permissions tightened from `contents: write` to `contents: read`, with per-job overrides where needed. Attestation step is gated on tag pushes so PR dry-runs don't pollute Sigstore's transparency log. - Opt-in provenance verification in all three installers, resolved via a three-layer precedence ladder: 1. CLI flag `--verify-attestation` / `-VerifyAttestation` 2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1` 3. Config `~/.plannotator/config.json` → `verifyAttestation: true` 4. Default off Off-by-default matches every major ecosystem installer (rustup, brew, bun, deno, helm) and avoids a UX failure for the majority of users who don't have `gh` installed or authenticated. Security-conscious users get three ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is missing so opt-in is never silently skipped. - `PlannotatorConfig.verifyAttestation?: boolean` added to `packages/shared/config.ts`. Pure additive schema change; no runtime consumer exists (the field is read only by the install scripts). No UI surface — this is an OS-level power-user knob only. - Documentation rewritten in README.md, apps/hook/README.md, and the marketing install page with both pinned-version examples and a "Verifying your install" section covering manual `gh attestation verify` and offline `cosign verify-blob` paths. - Release skill updated to note that the release pipeline now emits SLSA attestations and (post-merge) GitHub Immutable Releases will be enabled on the repo. Issue #506 (install.cmd crash on Windows when Gemini is present): Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2 parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom (`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically identical, and sidesteps cmd's parser entirely with no escape gymnastics and no new dependencies. Added regression test in scripts/install.test.ts that asserts the `||` form is present and `if(!s.hooks)` is absent, so re-introducing the bug would fail CI. Test suite expanded from 23 to 29 tests covering: - Gemini #506 regression - Three-layer opt-in wiring assertions for all three installers - install.sh guard check (the executable `gh attestation verify` call must live behind the `verify_attestation -eq 1` gate, so the default path never invokes gh) - PlannotatorConfig schema assertion Out of scope (tracked): - Immutable Releases toggle in repo Settings (one-click, post-merge). - SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires restructuring release.yml around a reusable workflow). - Issue #507 item 3: UI update-cooldown setting. For provenance purposes, this commit was AI assisted.
- docs: drop broken `cosign verify-blob` example. Verified against Sigstore's docs that `cosign verify-blob` requires `--bundle` (or `--signature` + `--certificate`); the shipped command provided neither and could not have worked. Replaced with the canonical `gh attestation verify --repo` flow (gh + auth required, but optional — only needed if a user wants to manually audit provenance) and a link to GitHub's offline-verification docs for advanced workflows. Applied to README.md, apps/hook/README.md, and the marketing install page. - docs: list per-platform binary paths in the manual verification examples. The previous snippets hardcoded `~/.local/bin/plannotator` even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users copying the snippet got file-not-found instead of a verification result. - install.sh: capture and surface `gh attestation verify` stderr on failure instead of redirecting to /dev/null. Diagnosability matches install.ps1, which already prints `$verifyOutput` on failure. The most common failure mode (`gh auth login` not run) is now immediately actionable instead of presenting as a generic "verification failed" error. - install.cmd: reject any unknown dash-prefixed token before the positional fall-through. A typoed `--verify-attesttion` no longer becomes `VERSION=--verify-attesttion` and 404s on a nonsensical download URL — it fails fast with `Unknown option:` and a usage hint. install.sh and install.ps1 already had equivalent guards (case `-*)` arm and PowerShell's strict param block respectively). All 29 install tests still pass. For provenance purposes, this commit was AI assisted.
Address the reviewer gap flagged in PR #512: the unit tests in scripts/install.test.ts only do file-content string matching on Linux and never execute cmd.exe, so the #506 fix (rewriting the embedded `node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`) was shipped without any runtime coverage. The previous CI only had ubuntu-latest runners. New `install-cmd-windows` job on `windows-latest`: 1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non- plannotator hook plus unrelated top-level keys (theme, general). The fixture mirrors the shape of a real Gemini settings.json but uses only obviously-fake values and contains no secrets. 2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end through real cmd.exe. This exercises the parser under `enabledelayedexpansion`, the embedded `node -e` merge script, and the full install flow. 3. Parses the post-install settings.json with PowerShell and asserts: - The plannotator hook was added to hooks.BeforeTool. - The pre-existing fixture hook is still present (regression guard for the original #506 bug, where cmd ate the `!` in `if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing arrays). - Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`) survived the merge untouched. 4. Separately exercises the new unknown-flag rejection added in the previous commit: invokes `install.cmd --verify-attesttion` (typo) via Start-Process and asserts exit code != 0. Before the review fix this would have silently set `VERSION=--verify-attesttion` and 404'd on the download. The job runs in parallel with the existing ubuntu `test` job (no deps, independent runner). Uses the v0.17.1 release as the binary source — that release is pre-PR, so the test is stable against release drift and is testing install.cmd's CODE, not any specific binary. This closes the CI gap where install.cmd had effectively zero runtime coverage and the original #506 bug could have recurred without anyone noticing until a user reported it. For provenance purposes, this commit was AI assisted.
…all.sh) Self-review catch: the PR #512 reviewer flagged install.sh for redirecting `gh attestation verify` output to /dev/null, which swallowed actionable error messages (auth missing, network issue, attestation not yet propagated) behind a generic "verification failed" line. I fixed install.sh in the previous review-fix commit but missed that install.cmd had the exact same pattern: gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1 Same bug, same consequence, same fix. cmd doesn't have bash's `$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect to a temp file and `type` it on failure, then clean up in both branches: gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1 if !ERRORLEVEL! neq 0 ( type "%TEMP%\gh-output.txt" >&2 del "%TEMP%\gh-output.txt" echo Attestation verification failed! >&2 ... ) del "%TEMP%\gh-output.txt" All three installers now surface gh's actual error message on failure, which makes the most common failure mode (`gh auth login` not run) immediately diagnosable on every platform. Note: this code path is not exercised by the new Windows CI integration job because that job passes `--skip-attestation`, and exercising the gh verify path would require an attestation for v0.17.1 to exist — which it doesn't, since v0.17.1 was released before this PR added the attestation step. The fix will first become CI-testable against the first post-merge release that carries a provenance bundle. For provenance purposes, this commit was AI assisted.
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
…er-workflow Addresses PR #512 review cycle 3 finding that repo-scoped verification alone doesn't bind the downloaded binary to the specific tag the user requested. A misattached release asset would pass the old check because the wrong binary would still carry a valid attestation for its own (wrong) commit. GitHub's own docs explicitly recommend both constraints: "The more precisely you specify the identity, the more control you will have over the security guarantees. Ideally, the path of the signer workflow is also validated." — https://cli.github.com/manual/gh_attestation_verify All three installers now pass: --source-ref "refs/tags/<requested-tag>" Enforces that the git ref the attestation was produced from matches the tag the installer asked for. Closes the misattached-asset gap. --signer-workflow backnotprop/plannotator/.github/workflows/release.yml Enforces that the attestation was signed by our release workflow file specifically, not any workflow in the repo. GitHub treats this flag as a regex (see cli/cli#9507) so future refactors can broaden the match without breaking version-pinned installs to historical releases. Also addresses the sibling finding that install.cmd used a fixed %TEMP%\gh-output.txt temp filename while the rest of the script uses %RANDOM% for uniqueness. Renamed to %TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern and removing a theoretical race between concurrent invocations. New test in install.test.ts asserts all three installers pass --source-ref and --signer-workflow with the expected values. 30 tests pass. For provenance purposes, this commit was AI assisted.
…m, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
Self-review catch on top of the cycle 5 commit: - `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed predictable path. Same concurrency + symlink-pre-placement class as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to fix two of three and leave the third. Renamed to `%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established pattern. The reviewer didn't flag this one — I missed it during the cycle 5 sweep. - Tightened the Out-String regression test from a weak "Out-String appears somewhere in the file" check to a regex matching the specific `$verifyOutput | Out-String` wiring. Previous assertion would have passed even if some future bug accidentally wrapped the mutex-guard string literal in Out-String while leaving $verifyOutput unprotected. - Expanded the randomized-temp-paths test to cover all four curl download targets (release.json, binary, checksum sidecar, gh output capture) rather than the two originally in scope, and to assert the old fixed paths (including checksum.txt) are gone. 35 tests still pass. For provenance purposes, this commit was AI assisted.
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes the three Claude Code slash command files (plannotator-review.md, plannotator-annotate.md, plannotator-last.md) via `echo` lines inside `setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips unmatched `!` characters — so lines like: echo !`plannotator review $ARGUMENTS` ended up in the written file as: `plannotator review $ARGUMENTS` without the leading `!`. The `!` prefix is what tells Claude Code to execute the backtick block as a shell command; without it, Claude Code renders the line as inline markdown code and the slash command is a silent no-op. The install appeared to succeed, but every Windows cmd user got three broken slash command files. install.sh (single-quoted heredocs) and install.ps1 (single-quoted here-strings) write the `!` correctly because their respective literal-string idioms bypass shell expansion entirely. install.cmd has no single-quote-literal equivalent — its escape hatch is `^!`. The Gemini section of install.cmd (lines 482, 495) already uses `^!` correctly; the Claude Code section didn't until now. Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368. Brings install.cmd into parity with the other two installers. No divergence introduced; existing divergence removed. Two regression guards added: - Unit test in install.test.ts asserts install.cmd contains the escaped form for all three command files and does not contain the unescaped form. - New step in the Windows CI integration job reads back each generated .md file from %USERPROFILE%\.claude\commands\ and asserts it contains the literal `!`\`plannotator` prefix. Catches the bug at the actual file-write level on a real Windows runner, not just via source-code grep. 36 install tests pass (was 35). Note: the broader architectural issue — all three installers carry hand-typed duplicates of command content that already lives at apps/hook/commands/*.md — is deferred to a follow-up issue. The cmd bug is the visibly-broken symptom; the deduplication is the long-term fix. For provenance purposes, this commit was AI assisted.
4 tasks
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
Pre-existing bug surfaced in PR #512 review cycle 7. install.ps1 detected ARM64 correctly and set $arch=arm64, constructing a URL for plannotator-win32-arm64.exe — which doesn't exist in any release. The release pipeline only builds bun-windows-x64 (release.yml line 88), so there is no native ARM64 Windows binary to download. With $ErrorActionPreference=Stop set at the top of the script, the resulting 404 on Invoke-WebRequest threw a terminating error and the install aborted with a stack trace. ARM64 Windows PowerShell users could not install plannotator at all. Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets ARM64 hosts pass the arch check, silently installs the x64 binary and relies on Windows 11's x86-64 emulation layer to run it. This is accidentally the useful behavior — imperfect, but the user gets a working install instead of a hard failure. This commit brings install.ps1 into parity with install.cmd's (accidentally correct) behavior: - On 64-bit Windows, $arch is unconditionally "x64" — no more branch for arm64 that would download a nonexistent binary. - When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice telling the user they're getting the x64 binary via Windows emulation so the behavior isn't silent. - 32-bit Windows still errors out (unchanged). Both Windows installer paths now produce a working install on both x64 and ARM64 hosts. No release pipeline changes. No new binaries. The test `detects ARM64 architecture` used to be a weak string- presence check that passed whether the ARM64 branch selected arm64 or x64. Rewrote it to assert the actual new contract: ARM64 is detected (for the notice), $arch is hardcoded to "x64", and the previous `{ "arm64" }` branch is gone so the regression can't silently return. Native ARM64 Windows builds tracked as a follow-up — requires verifying Bun's Windows ARM64 target support and adding bun-windows-arm64 to the release matrix. For provenance purposes, this commit was AI assisted.
PR #512 cycle 7 review surfaced that opt-in provenance verification was dead-on-arrival for the window between this PR merging and the first post-merge release: - The docs showed `--version v0.17.1` as the pinned example. v0.17.1 was cut before this PR added attestation generation to release.yml, so any user copy-pasting the example AND enabling verification would hit a cryptic `gh: no attestations found` error and a hard install failure. - Default installs with verification enabled (via flag, env var, or config file) resolve `latest` to v0.17.1 and hit the same failure with no user-visible pinned version to "blame." Medium fix (better error message) was dismissed as lipstick — the install still fails, just with nicer wording. This is the maximum fix that actually prevents the failure path by checking the resolved tag against a hardcoded floor BEFORE downloading. ## Changes `scripts/install.sh`: - New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top - New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0) - Moved three-layer verification resolution (config → env → flag) to before the download so $verify_attestation is known in time to gate network work - New pre-flight check: if verification is requested and the resolved tag is older than MIN_ATTESTED_VERSION, fail fast with a clean message listing recovery options (pin to newer version, --skip-attestation, or unset the env var / config). No binary download, no wasted SHA256 check. - Late `gh attestation verify` block now only handles the gh call itself — resolution and pre-flight moved upstream. `scripts/install.ps1`: - New `$minAttestedVersion = "v0.18.0"` constant - Pre-flight guard in the verification branch using PowerShell's [version] class for proper numeric comparison - Same error message content as install.sh `scripts/install.cmd`: - New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup - Pre-flight guard shells out to PowerShell for semver comparison — Windows 10+ ships `powershell.exe` always, so no new runtime dependency. Hand-parsing semver in cmd was tried and rejected as too fragile for prerelease tags and non-numeric components. `apps/marketing/.../installation.md`, `apps/hook/README.md`, `README.md`, `scripts/install.sh --help`: - Replaced every user-facing `v0.17.1` example with `vX.Y.Z` placeholder. The placeholder pattern already exists in the "Verifying your install" section, so this is just consistency. - install.sh --help adds a link to the releases page so users know where to find actual tag values. `.agents/skills/release/SKILL.md`: - New Phase 4 checklist step: before shipping the first attested release, verify MIN_ATTESTED_VERSION in all three installers matches the tag being cut. The constant is bumped ONCE and never again — it's a permanent floor, not a moving target. If the first post-merge release is not v0.18.0, the skill updates the constant in the same commit as the version bump so the installers served from plannotator.ai activate the new floor at the same moment the first attested release becomes fetchable. `scripts/install.test.ts`: - New test asserts all three installers hardcode MIN_ATTESTED_VERSION, use appropriate version comparison for their dialect, and contain the "predates" error message - New test asserts install.sh and --help text no longer contain `v0.17.1` as a pinned example 38 install tests pass (was 36). Smoke-tested install.sh end-to-end: - `--version v0.17.1 --verify-attestation` → pre-flight rejects cleanly, no download attempted, exit 1 with actionable error - `--version v0.18.0 --verify-attestation` → pre-flight passes, script proceeds to download (404 as expected since v0.18.0 is not yet released) - `--version v0.17.1` (no verify) → pre-flight skipped, normal download path For provenance purposes, this commit was AI assisted.
…nload PR #512 review cycle 8 raised three related findings, all verified against actual code. ## Critical: PowerShell command injection in install.cmd (Finding 2) Line 228 of the previous install.cmd passed the version comparison to PowerShell by interpolating delayed-expansion variables directly into the command string between single-quoted literals: for /f "delims=" %%i in ('powershell -NoProfile -Command "try { if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' } } catch {}"') do set "VERSION_OK=%%i" The arg parser rejected leading-dash values but not quotes or semicolons, so a user passing install.cmd --version "0.18.0'; calc; '0.18.0" produced the PowerShell command try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0') { 'yes' } } catch {} PowerShell permits statement sequences inside `if` condition parentheses — the last value is used — so `calc` executed as a side effect during the first evaluation phase. Attacker-controlled --version from a CI/CD wrapper (PR titles, external tag sources, etc.) equals arbitrary code execution as the invoking user. Fixed by passing the version strings via environment variables ($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into the PowerShell command string. PowerShell reads $env: values as raw strings and never parses them as code. The [version] cast throws on invalid input, catch {} swallows it, VERSION_OK stays empty, and the guard rejects — safe fail with a slightly less helpful but correct error message. ## Structural: Windows pre-flight ran post-download (Findings 1 & 3) install.sh was already restructured in the previous commit to run the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the binary download, so users hit the "predates attestation support" error without wasting bandwidth. install.ps1 and install.cmd drifted — their resolution and pre-flight blocks stayed in their original post-SHA256 positions, meaning the binary was always downloaded and SHA256-verified even when the requested tag was doomed to fail provenance verification. The "Pre-flight: reject the verification request before downloading" comments were lies copied from install.sh. This commit moves both Windows installers' resolution + pre-flight blocks upstream of the download: install.ps1: resolution + pre-flight now run immediately after `Write-Host "Installing plannotator $latestTag..."`, before $tmpFile is created or Invoke-WebRequest runs. The late gh-call block keeps only the gh attestation verify call itself. install.cmd: same restructure. The late block keeps only the where-gh check and gh invocation. The `del "!TEMP_FILE!"` calls inside the rejection branch are gone (TEMP_FILE doesn't exist yet when the guard runs). ## Tests Added two new regression guards to scripts/install.test.ts: 1. Order-aware check for all three installers: the resolution block's opening line must appear textually BEFORE the curl / Invoke-WebRequest download line. Uses indexOf to compare positions. Catches any future regression that drifts the pre-flight back after download. 2. Injection-safe pattern check for install.cmd: asserts the PowerShell command references $env:TAG_NUM / $env:MIN_NUM and does NOT interpolate !TAG_NUM! / !MIN_NUM! between single quotes in any [version] cast. 40 install tests pass (was 38). Smoke-tested install.sh with --version v0.17.1 --verify-attestation — rejects cleanly with no download, same as before. For provenance purposes, this commit was AI assisted.
…andling PR #512 cycle 9 review surfaced three real findings, all verified. ## Finding 1 (important): Windows CI never exercised the attestation path The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`, which bypasses every bit of logic this PR shipped: three-layer opt-in resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell version comparison, and the gh attestation verify call. A runtime bug in any of those paths would not be caught by CI. `--skip-attestation` was passed intentionally because v0.17.1 predates attestation support — running without it hits the pre-flight and rejects. But that's the point: the REJECTION path is a real, valid end state we can assert against. The previous test conflated "install should succeed" with "test should pass"; the fix is to assert the correct behavior for an old version. Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation` via Start-Process with stderr redirection to a temp file, then asserts: - exit code != 0 (pre-flight rejected) - stderr contains "predates" (rejection came from our guard, not some other failure mode like a network error or gh missing) This exercises on a real cmd.exe: - setlocal enabledelayedexpansion parser under the guard - three-layer resolution reaching the CLI flag layer - the :~1 substring (instead of the previous :v= global substitution) - the pre-release tag detection (negative path for stable tags) - the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM - the [version] -ge comparison returning false - the "predates" error message block Can't test the success path (valid attested release) until the first post-merge release exists. Tracked for follow-up. ## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!` replaces every occurrence of `str` globally. For all current semver tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence. A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2, which [System.Version] can't parse, silently misclassifying the failure as "predates attestation support" (see Finding 3). install.ps1 line 121 uses `-replace '^v', ''` which is properly regex-anchored. install.cmd had no anchored equivalent. Fixed by using `!TAG:~1!` — substring from index 1 — which drops exactly the first character. Safe because TAG is guaranteed to start with `v` by the normalization step upstream (line ~141). ## Finding 3 (nit): Pre-release tags misdiagnosed on Windows [System.Version] doesn't support semver prerelease or build-metadata suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version string. The catch blocks in both Windows installers handled the throw but surfaced wrong/confusing errors: install.sh: handles prereleases correctly via `sort -V` (POSIX version sort is semver-aware) — no issue. install.ps1: caught and printed "Could not parse version tags for provenance check" — accurate but doesn't explain WHY. install.cmd: swallowed silently, VERSION_OK stayed empty, printed "predates attestation support" — actively wrong, the problem isn't the version's age. Fixed in both Windows installers by detecting `-` in the tag BEFORE attempting the [version] cast: install.ps1: `if ($latestTag -match '-')` → dedicated error install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native substitution check, no subshell, no metacharacter risk) Both emit a clear "pre-release tags aren't currently supported for provenance verification on Windows" message pointing users at --skip-attestation or a stable tag. Windows has no built-in semver comparator; adopting one would require NuGet or a custom parser. Explicit rejection with honest diagnosis is the pragmatic choice. ## Tests Three new regression guards in install.test.ts: 1. `install.cmd strips leading v via substring, not global substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!` is gone. 2. `both Windows installers reject pre-release tags with a dedicated error` — asserts both scripts contain the "Pre-release tags" error message and the appropriate detection pattern for their dialect. 3. The new test.yml CI step doubles as a runtime regression guard — any break in the cmd pre-flight path that no longer matches "predates" in stderr, or returns 0, fails CI. 42 install tests pass (was 40). Windows CI will now exercise the pre-flight rejection path end-to-end for the first time. For provenance purposes, this commit was AI assisted.
…misc PR #512 cycle 10 raised four findings, all verified. ## Finding 1: id-token/attestations permissions granted to build on PRs The build job in release.yml had `id-token: write` and `attestations: write` at the job level with no conditional guard. On PR triggers, those permissions were live for every build step (checkout, bun install, bun build, compile) even though the attestation step itself was gated by `if: startsWith(github.ref, 'refs/tags/')`. Narrow-but-real attack surface: a trusted contributor's malicious PR injecting code into a build step could mint an OIDC token authenticating as the repo identity. Fork PRs are automatically protected (GitHub suppresses OIDC tokens on forks), but same-repo contributor compromise is a realistic risk in a project with external contributors. Fixed by splitting attestation into its own job: build: contents: read only. Runs on all triggers. Compiles binaries and uploads them as the `binaries` artifact. No OIDC capability anywhere in the job. attest: needs: build, if: tag push only. contents: read + id-token: write + attestations: write. Downloads the binaries artifact and runs attest-build-provenance. Permissions are only live when we're actually producing an attestation — never on PR dry-runs. release: needs: attest (was: needs: build). Still tag-only. The dependency chain guarantees the attestation exists in the GitHub attestation store before the release's binaries are published, closing the race window where a user could pull the binary and gh attestation verify would fail because the bundle hadn't propagated yet. npm-publish: unchanged. Still needs: build. Still has id-token: write for `npm publish --provenance`. The reviewer flagged only the build job; npm-publish's id-token grant is scoped to that one job and is actually used by the provenance flag. ## Finding 2: CI test promised a binary-preservation check but didn't do one The `Attestation pre-flight rejects v0.17.1` step contained a multi-line comment promising to verify the rejected run didn't overwrite the previously-installed binary. No assertion code followed — just a Write-Host success line. The test claimed more than it delivered. Added actual baseline capture + comparison: - Before running the rejection test, capture the binary's SHA256 and LastWriteTime from the prior Gemini-merge step. - After the rejection, recompute both and assert they match. - Any drift throws: catches future regressions that re-introduce the post-download pre-flight pattern (the pre-flight correctly rejects but only after downloading and overwriting the file). ## Finding 3: install.ps1 dead-code comment about flag precedence Line 111 read "-SkipAttestation beats -VerifyAttestation if both passed" but the upfront mutex guard (lines 13-16) exits 1 if both flags are present. The "beats" scenario is unreachable. The comment misleads a future reader into thinking the late ordering handles the mutual exclusion and is safe to remove the early guard — which would be backwards. Replaced with a comment that explicitly notes the mutex guard at the top of the script makes the two branches mutually exclusive by construction. ## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure The skills-install block chained `git clone ... && cd ... && git sparse-checkout set ...`. If clone succeeded but sparse-checkout failed, the short-circuit skipped the `cd -` and `rm -rf "$skills_tmp"` later ran with the shell's CWD still inside the to-be-deleted directory. On Linux/macOS this silently "works" — the inode is unlinked but the process keeps its cwd reference — so nothing visibly breaks (all downstream code uses absolute paths). But it's structurally wrong: install.ps1 and install.cmd both use Push-Location/pushd for the same logic. Restructured to run the entire clone → sparse-checkout → verify → copy sequence inside a single `(...)` subshell, with `cd`s scoped to the subshell. The parent shell's CWD is unchanged regardless of which step fails, so the subsequent `rm -rf` always runs from a stable location. Any failure in the chain short-circuits to the else branch with a clean skip message. Also merged the two `[ -d ]` / `[ ls -A ]` guards into the chain so the "apps/skills empty" case is now reported in the skip message rather than being silently suppressed. 42 install tests pass. For provenance purposes, this commit was AI assisted.
…note Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the three installers as a best-guess for the first post-merge release, and I added a one-time bump instruction to the release skill as insurance in case the guess was wrong. The guess was wrong — the next release is v0.17.2 (patch bump, not a minor bump). Updated the constant in all three installers and the matching test assertions. No other version references in the shipped error messages need changing because they read MIN_ATTESTED_VERSION from the variable at runtime. Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section from .agents/skills/release/SKILL.md entirely. With the constant now set to the actual next release tag, there's nothing for the release agent to bump at release time — the constant is already correct. Baking a one-time action into a recurring release skill was the wrong place for it; every future release agent would read the warning, confirm it's already set, and move on. Noise in a workflow that's supposed to be tight. If the next release version ever differs from v0.17.2 (e.g. we decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting that release will need to update MIN_ATTESTED_VERSION in the three installers. That's an ad-hoc fix, not a recurring skill concern. Smoke test with the new value: - install.sh --version v0.17.1 --verify-attestation → rejects with "first attested release is v0.17.2" - install.sh --version v0.17.2 --verify-attestation → passes pre-flight, proceeds to download (404 as expected since v0.17.2 is not yet released) 42 install tests pass. For provenance purposes, this commit was AI assisted.
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
…ll.cmd Self-review catch on top of the ARM64 support commit. My install.ps1 architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which reports the architecture the CURRENT PowerShell process is running under — not the host architecture. On ARM64 Windows, a 32-bit PowerShell process (rare, but possible) would see PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to \$arch = "x64", and download the emulated x64 binary instead of the new native arm64 build. install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432, which is set only in 32-bit WoW64 processes and holds the host architecture. install.ps1 was the odd one out. Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same detection logic regardless of process bitness. Also added an explicit error branch for unrecognized architectures (anything that isn't AMD64 or ARM64) instead of silently assuming x64. Test updated to assert both env vars are referenced. For provenance purposes, this commit was AI assisted.
… docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
Self-review catch: the cross-file consistency test added in the prior commit matched the assignment form anywhere in each file. No current comment triggers a false positive, but a future comment like `# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and shadow the real assignment, causing the test to report the wrong value or pass when it shouldn't. Hardened by adding /m flag and ^ anchor. The real assignments in all three installers are flush-left at the top of their files, so requiring line-start is both safe (won't reject current code) and stricter (future comments with leading whitespace or other prefixes are ignored). 44 tests still pass. For provenance purposes, this commit was AI assisted.
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
…ndows Two stale references in .agents/skills/release/SKILL.md after the ARM64 Windows binaries were added: - "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)" → "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)" - "Compiles paste service binaries (same 5 platforms)" → "Compiles paste service binaries (same 6 platforms)" - "Generates SLSA build provenance attestations for all 10 binaries" → "Generates SLSA build provenance attestations for all 12 binaries" The first two predate this PR; the third was added in the cycle-1 commit and not bumped when the ARM64 Windows targets landed in the ARM64 commit. All three corrected together so the release agent sees an internally-consistent description of what the pipeline actually does. Verified against release.yml — 12 entries in the attest job's subject-path list, 12 compile commands in the build job, all six platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64) for both plannotator and paste-service. For provenance purposes, this commit was AI assisted.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #507 (items 1 & 2) and #517, fixes #506.
Summary
--version v0.X.Yflag (and positional form) on all three installers; default stayslatestso every documentedcurl | bashinvocation works unchanged.actions/attest-build-provenance(SHA-pinned to v4.1.0) signs all 10 released binaries via Sigstore. Top-level workflow permissions tightened tocontents: readwith per-job overrides.~/.plannotator/config.json) with documented precedence. Off by default to match every major ecosystem installer (rustup, brew, bun, deno, helm) and avoid hard-failing for users withoutghset up.enabledelayedexpansionwas eating the!chars in the embeddednode -eJS. Rewrote the merge script to uses.hooks = s.hooks || {}(no!characters), sidestepping cmd's parser entirely.Why opt-in verification, not on-by-default
I originally shipped on-by-default
gh attestation verify, butgh attestation verify --reporequiresgh auth login. Many users haveghinstalled via brew/scoop/apt without ever logging in — they would have hit a confusing hard failure on every install. After auditing how rustup, brew, bun, deno, helm, nvm, and even cosign's own installer handle this (all use SHA256+HTTPS only), the right default is opt-in.Power users now have three ways to enable auto-verification:
Precedence: CLI flag > env var > config file > default (off). When enabled, the installer hard-fails if
ghis missing so opt-in is never silently skipped.Manual verification (anyone, anytime)
The attestations exist in Sigstore + GitHub's attestation API regardless of installer settings. Anyone can verify a downloaded binary:
SLSA level
This gets us SLSA Build L2, not L3. L3 requires build isolation that
actions/attest-build-provenanceon a regularubuntu-latestjob doesn't provide — reaching L3 needsslsa-framework/slsa-github-generator's reusable workflow, which would mean restructuringrelease.ymlaround a called workflow. Tracked as a follow-up. L2 still gives every released binary a Sigstore-signed link to its source commit and workflow run, which is the leap from "maintainer-generated SHA256 only" that issue #507 actually asked for.Files touched
scripts/install.sh--versionflag, three-layer opt-in resolution, hardened arg parserscripts/install.ps1-Version/-VerifyAttestationparams, ConvertFrom-Json config read, strict bool checkscripts/install.cmd--versionalias, three-layer opt-in, #506 fix: rewrote Gemini merge JS to use||idiom.github/workflows/release.ymlattest-build-provenancestep (tag-gated), tightened permissionspackages/shared/config.tsverifyAttestation?: booleantoPlannotatorConfig(additive, no consumers in runtime code)README.md,apps/hook/README.md,apps/marketing/.../installation.md.agents/skills/release/SKILL.mdscripts/install.test.tsTest plan
bun test scripts/install.test.ts— 29/29 passbash -n scripts/install.sh— syntax OKbash scripts/install.sh --help— usage block renderstestworkflow on this PRreleaseworkflow in dry-run mode (PR-triggered) to confirm the build job + new attestation step work end-to-endgh attestation verify <binary> --repo <fork>succeedsinstall.cmdand confirms Error with installation : "TypeError: Cannot read properties of undefined (reading 'BeforeTool')" #506 no longer crashesPost-merge action required
Enable Immutable Releases in repo Settings → General → Releases. This is a one-click toggle that closes the "asset swap post-publish" attack vector by making tag→commit and tag→asset bindings permanent. Release notes remain editable, so the existing release workflow is unaffected. See https://docs.github.com/en/code-security/concepts/supply-chain-security/immutable-releases.
Out of scope (tracked)
slsa-framework/slsa-github-generator(release.yml refactor)For provenance purposes, this PR was AI assisted.