Skip to content

feat(attest): platform-aware action for Windows / GHES [RC]#114

Draft
ronens88 wants to merge 7 commits into
mainfrom
feature/windows-ghes-attestation
Draft

feat(attest): platform-aware action for Windows / GHES [RC]#114
ronens88 wants to merge 7 commits into
mainfrom
feature/windows-ghes-attestation

Conversation

@ronens88
Copy link
Copy Markdown
Contributor

@ronens88 ronens88 commented May 1, 2026

Summary

Make the `./attest` action cross-platform so customers on Windows GHES self-hosted runners can use it. Companion to cimon#1452 — both branches together form the Digital Grid RC.

Changes

  • `attest/index.js` — branches on `process.platform`. Linux/macOS uses `install.sh` + `sh`; Windows uses `install.ps1` + `pwsh`. Paths use `$RUNNER_TEMP` (set by GHES on every platform) instead of hardcoded `/tmp`. Binary name flips to `cimon.exe` on Windows.
  • `attest/README.md` — proper readme covering cross-platform quickstart, GHES configuration, and signing options for USA data-residency customers (KMS / private Sigstore / keyed offline).
  • `verify-pr.yaml` — new `verify-attest-windows` job that runs `./attest` on `windows-latest` against a sample artifact with keyed signing. Validates platform branching and serves as a customer reference.
  • `build-attest-dist.yaml` — CI helper that auto-rebuilds `attest/dist/index.js` (the bundled distribution the runtime executes) when `attest/index.js` changes. Needed because changes to the unbundled source aren't picked up at runtime.

Notes

  • `attest/dist/index.js` is intentionally not regenerated in this commit — `build-attest-dist.yaml` will refresh it on PR push automatically. Alternately a release machine can run `npm ci && npm run dist/index.js` before tagging.
  • Companion install.ps1 lives in cimon repo at `scripts/install.ps1`.

Test plan

  • `build-attest-dist` workflow regenerates `attest/dist/index.js` on this PR
  • `verify-attest-windows` job passes on `windows-latest`
  • Existing `verify` (Linux) job still passes — platform branching shouldn't regress Linux
  • After both repos green: tag matching RC versions, ship to Digital Grid

🤖 Generated with Claude Code

ronens88 and others added 7 commits May 1, 2026 15:28
attest/index.js no longer assumes Linux: it picks install.sh + sh on
Linux/macOS and install.ps1 + pwsh on Windows. Paths use $RUNNER_TEMP
(which GHES sets on every platform) instead of hardcoded /tmp, and the
binary name flips to cimon.exe on Windows. The corresponding
install.ps1 lives in the cimon repo.

attest/README.md is now a real readme covering the cross-platform
quickstart, GHES configuration, and signing options for customers with
US data-residency requirements (KMS / private Sigstore / keyed
offline).

verify-pr.yaml gains a Windows job that runs the same ./attest action
the customer would use, against a sample artifact, with keyed signing.
This both validates the platform branching and serves as a reference
example.

build-attest-dist.yaml is a CI helper that automatically rebuilds
attest/dist/index.js (the bundled distribution the runtime executes)
whenever attest/index.js changes — needed because changes to the
unbundled source are not picked up at runtime.

Note: attest/dist/index.js is intentionally not regenerated in this
commit. CI (build-attest-dist) will refresh it on the PR; alternately
a release machine can run npm ci && npm run dist/index.js before tag.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The Windows verify-attest-windows job needs CIMON_CLIENT_ID and
CIMON_SECRET to authenticate with the Cycode backend before it can
upload provenance. Mirror the existing pattern used by the Linux
verify-provenance job.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…elease

The Windows verify-attest job depends on install.ps1 being published
to cimon-releases.s3.amazonaws.com. Until the first Windows-supporting
RC is tagged and the script is uploaded, the job will fail at the
download step.

The actual end-to-end Windows attestation flow is exercised in the
cimon repo's ci_test_attest_windows.yaml workflow, which builds the
binary in CI and uses it directly without going through S3 — that's
the workflow that validates the demo.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ecycle scripts

Security review surfaced two issues on the action side:

1. (high) attest/index.js installed cimon under $RUNNER_TEMP/cimon
   and skipped the install if that path already existed. On a
   self-hosted runner with state persistence between jobs (typical
   for GHES Windows self-hosted), a malicious earlier step could
   plant cimon.exe at the expected path and the action would
   silently execute it. Fix:

     - scope every install under
       $RUNNER_TEMP/cimon-<run_id>-<run_attempt>-<job>/
       so a different job can't pre-populate the same path,
     - rmSync(dir, recursive) the per-job dir before installing,
       defending against in-job planting too,
     - always re-download the install script (no fs.existsSync
       short-circuit anymore).

2. (medium) build-attest-dist.yaml ran "npm ci" with lifecycle
   scripts enabled (postinstall etc.) under contents:write
   permission. A PR adding a malicious dependency could have
   executed arbitrary code in CI before the auto-commit landed.
   Fix:

     - npm ci --ignore-scripts (ncc bundling doesn't need them),
     - the auto-commit step now refuses to commit unless the only
       changed file is exactly attest/dist/index.js. Anything else
       fails the workflow with a visible error, which is much
       louder than an unexpected commit landing under
       github-actions[bot].

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
cycodelabs/cimon-action@v0 is the legacy line — frozen at f99ad55,
predates hardening (PR #104) and predates the platform-aware Windows
install added in PR #114. cycodelabs/cimon-action@v1 is the line that
follows main and will pick up the Windows changes once that PR merges
and v1 is force-updated.

Today attest@v0 and attest@v1 are byte-identical, but documenting
@v0 in customer-facing examples is a footgun: when our Windows
support lands and v1 advances, customers pinned to @v0 will silently
keep getting the Linux-only attest action.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant