Download CI/lock

Install

Linux and macOS

curl -fsSL https://cilock.dev/install.sh | bash

The script picks your OS and architecture and installs the latest stable release (set CILOCK_VERSION for another one). Before it installs anything it checks the archive's SHA-256 against the manifest, then checks the Sigstore signature on the binary with openssl against a Sigstore root and Rekor key pinned inside the script. It refuses to install unless the signer is release-fanout.yml in testifysec/judge, run at that version's tag or on main. It does not run cilock verify; that is the last step under Verify your download. The script itself comes from cilock.dev, so read it first: curl -fsSL https://cilock.dev/install.sh.

Windows

There is no install script for Windows. Download the .zip for your architecture from the table below. It holds cilock.exe. The PowerShell recipe in the install docs downloads it and checks the SHA-256 before extracting.

Next: gate your coding agent's pushes

Pushgate stands between a coding agent and GitHub. It refuses a push that cilock did not sign, and it checks the evidence cilock recorded against your policy before the push reaches the repository. Watch one gated push in a sandbox first. It needs no account.

Try Pushgate with no account →

Package managers

Homebrew pins every download by SHA-256, and its formula points at the same archives on cilock.dev. Upgrade with brew upgrade cilock.

Latest release

Loading the latest release…

How we sign

Two separate signatures cover a release, from two different trust roots, plus a policy gate in front of both.

1. Build evidence, signed by the TestifySec platform. The release workflow (release-fanout.yml in testifysec/judge, on GitHub Actions) builds each binary under cilock run. cilock records a source-git and a build attestation and signs each one keyless: the workflow's GitHub OIDC token is exchanged for a short-lived certificate from the TestifySec platform Fulcio, and an RFC 3161 timestamp from the platform TSA lets the signature verify after the certificate expires. No long-lived signing key is involved. These two files sit beside every archive.
2. A signed release policy decides what may publish. The policy (release-policy.json) names the workflow identity, repository and steps a valid release must have. It is itself signed with a short-lived platform certificate for cole@testifysec.com. Before a binary is uploaded the pipeline runs cilock verify against it, and an archive that fails does not publish.
3. Sigstore signature on the binary. After that gate, the same workflow signs the cilock binary inside each archive with cosign sign-blob against public Sigstore (Fulcio and Rekor), using its GitHub identity. The bundle is the .cosign.bundle file. The release pipeline re-verifies each bundle against the final bytes before publishing; if Sigstore is unreachable the archive ships without a bundle and with a .cosign.failed marker. v4.10.0 has a bundle for all six cilock archives; earlier releases (v4.9.0 and before) have them for Linux only.

What is not signed today.

• No Apple signature or notarization. The macOS binaries carry only the ad-hoc signature the Go linker adds. spctl --assess --type execute rejects the v4.10.0 Apple Silicon binary. Each macOS archive ships a .sign.skipped marker that says so.
• No Authenticode signature on cilock.exe, for the same reason. Windows archives ship the same marker. Both gaps exist because signed publishing is switched off in the release workflow (RELEASE_SIGNED_PUBLISH_ENABLED defaults to false) and no OS signing credentials are configured.
• The manifest and install.sh are not signed. /dl/manifest.json and the .sha256 files catch a broken download, not a swapped one. The script's own protection is the Sigstore check described above. install.sh.sig does not exist.
• The .vsa.json files are plain JSON, not signed envelopes: a record of the pipeline's own verify result, not proof you can check.
• APT and DNF metadata will be signed with an OpenPGP key held in AWS KMS, through the release signer. Nothing is published there yet (see the table above).

What it proves: who built the binary, from which commit, and that the release passed its policy. What it doesn't prove: that the code is free of defects, or that the release runner was uncompromised.

Verify your download

Three checks, each stronger than the last. The commands are filled in for a Linux or macOS archive.

1. SHA-256

Confirms the archive matches the published checksum. The .sha256 file also lists the attestation files, so the command picks out the archive's own line. On Linux, sha256sum -c - works in place of shasum -a 256 -c -.

Loading…

2. Sigstore signature

Needs cosign. This checks the signature on the extracted binary and its Rekor log entry. The identity pattern accepts the workflow run at this version's tag or on main: v4.10.0 was signed from a run on main.

3. Build provenance against the release policy

Checks the binary against the signed policy and the two attestations. Run it with a cilock you already trust, such as a prior install, and not the one you just downloaded: a tampered binary can report success about itself. The verifier must be a release-built cilock, which carries the platform Fulcio and TSA roots; a source build stops with "must supply a public key, CA certificates, a verifier, or a cilock built with embedded policy trust". --platform-url "" keeps it fully offline.

Success ends with Verification succeeded and a line binding the binary's SHA-256 to the build step. On Windows, extract cilock.exe from the zip and use the windows files; cosign and cilock verify take it the same way. Air-gapped variant with explicit trust roots: Verify a release offline. All the options, including macOS quarantine: Verify the cilock binary.

License

CI/lock is open source under the Apache License 2.0. You can build your own binary from rookery. The default release ships the file, fulcio and piv signers; everything else is opt-in.