Security and releases

Genie runs on your machine with your permissions, so every release is signed, and install and update verify the signature before they unpack anything.

After the CanisterWorm supply-chain compromise, Genie left npm: it now ships only as signed GitHub Releases. The incident record covers what happened and how to check a host.

How a release is signed

Each release is signed with cosign keyless signing through GitHub Actions OIDC. There is no long-lived signing key to steal.
Every platform tarball ships with a cosign bundle, SLSA provenance and a GitHub attestation, bound to the source repository and to the workflow that built it.
Published release files are never replaced. Every release gets a new version and its own tag.

How install and update verify it

Every release is cosign-signed with SLSA provenance, and genie update verifies it offline, with no GitHub credential.

install.sh reads the channel manifest, downloads the release for your platform and checks its GitHub attestation with gh attestation verify, falling back to cosign verify-blob on the signature bundle. If neither check passes, it refuses to install, and it unpacks nothing before one does.
genie update checks the release's signed delivery evidence against a Sigstore trust root built into the binary, with the publishing workflow's identity pinned, and checks the downloaded tarball against the digest recorded in that evidence before it extracts anything. It also runs gh attestation verify as a cross check. If gh reports that the tarball does not verify, the update stops. If the check cannot run, because gh is missing or has no credential or no network, the update logs it as unavailable and proceeds on the offline proof.
Channels. The .well-known/latest.json and dev.json manifests in the repository decide which release is stable and which is dev. GitHub's "latest release" label does not.

Installation has the install and update commands.

The pinned identity

What you verify is the identity of the workflow that signed the release:

123certificate-identity-regexp: ^https://github\.com/automagik-dev/genie/\.github/workflows/sign-attest\.yml@refs/heads/main$
certificate-oidc-issuer:     https://token.actions.githubusercontent.com
provenance source-uri:       github.com/automagik-dev/genie

The same values are published in these places, all in the genie repository:

Where	What it is
`SECURITY.md`	The repository's security policy
`.well-known/security.txt`	The repository's `security.txt`
In-repo witnesses	`.github/cosign.pub`, `.github/ISSUE_TEMPLATE/signing-key-fingerprint.md`, `scripts/verify-release.sh` and `install.sh`

If any of them disagree, do not install, and report it. scripts/check-fingerprint-pinning.sh checks that every copy listed here agrees, and CI runs it on every pull request that changes SECURITY.md, .well-known/security.txt, the issue template or .github/cosign.pub. Key rotation is the runbook for changing the identity.

Verify a release yourself

From a clone of the genie repository, with cosign and slsa-verifier installed:

12345# Download every tarball of a release and verify each one (needs gh)
scripts/verify-release.sh <tag>

# Verify one tarball you already have, with its .bundle and .intoto.jsonl beside it
scripts/verify-release.sh --local genie-<version>-<platform>.tar.gz

The script runs cosign verify-blob and slsa-verifier against the pinned identity. SECURITY.md lists the underlying commands for a host where the script cannot run.

If you suspect a host

Genie has no host scanner, and the genie sec command of earlier releases is gone. If a host may have run a compromised build, isolate it, preserve the evidence and rotate its credentials from a separate trusted host. A fresh Genie install on that host proves nothing about the host itself. The CanisterWorm record lists the manual checks for that incident.

Report a vulnerability

Do not open a public issue. Report privately through a GitHub security advisory or by email to privacidade@namastex.ai. SECURITY.md has the response times.

Ask AI about this page