Reject a release from the wrong producer

A deployment gate accepts any signed artifact. A valid signature from an unrelated repository can therefore reach production. Repair the trust policy applied to verified evidence.

Requires Node.js 22 or newer. No package installation or server needed. To work in a container instead, open the folder with VS Code Dev Containers or GitHub Codespaces: .devcontainer/devcontainer.json uses the Dev Containers Node.js 24 image, pinned by digest.
1. Unzip all files into one folder.
2. In that folder, run: node --test exercise.test.mjs
3. Edit release-policy.mjs, then run the same command again.

The starter deliberately fails some tests. A successful repair passes every case, including cases that catch common wrong fixes. The browser runs this same cases.mjs with the same fixtures; locally Node runs your code directly. If you completed the optional first stage in the browser, Download my work adds your input as stage1-input.json and the tests include it. Only run code you wrote or reviewed.

1. Separate validity from trust
Run the wrong-repository case. The verifier authenticated a signature, but the signer is not your release producer.

2. Bind the artifact
Require evidence.verified === true and match the digest against the artifact being promoted. Never accept a truthy string as verification.

3. Bind producer and source
Compare repository, workflow, ref and sourceCommit with the supplied policy. A feature branch or another workflow is not the production release process.

4. Keep the valid release working
Run every test including a legitimate release. In a real pipeline apply this decision to the exact verified digest, then deploy that digest rather than a mutable tag.

SUPPLIED CONTRACT
allowRelease(evidence, policy) receives trusted verifier output, not caller-supplied claims. Evidence contains verified, digest, repository, workflow, ref and sourceCommit. Policy pins expected values. Return true only when every property matches and verified is exactly true.

REFERENCE
reference.mjs contains an explained solution: verified=true is necessary but insufficient. The allowed release also matches sha256:release-A, repository acme/invoices, workflow release.yml, ref refs/tags/v1 and sourceCommit commit-A. Changing any one field yields false, even if the verifier authenticated the statement. The string "true" is rejected because it is not the verifier’s boolean result. Once this gate allows the release, deployment must still use that verified digest; pulling a mutable tag later would create a new artifact-selection decision.

SCOPE
The exercise tests policy on trusted verifier output; it does not implement signature verification. Use a maintained verifier with the expected issuer/identity, trust roots and transparency policy. A client cannot self-assert verified=true.

NEXT TASK
Where is verifier output bound to the artifact that your deployment system actually pulls?

SOURCE
https://docs.sigstore.dev/cosign/verifying/verify/
