Signed commits, signed builds, signed reviews
Where GitHub commit signing, Sigstore gitsign, SLSA and GitHub artifact attestations, and a PatchArc .parc capsule each fit, what each signature proves, and how they combine.
updated 2026-08-22 · competitor pricing and claims checked 2026-08-22 · PatchArc facts as of 0.2.0
Three different things get signed in a software supply chain, and people regularly reach for one expecting the guarantees of another. A signed commit binds an author to a change. A build attestation binds an artifact to the process that produced it. A PatchArc capsule binds a review and its evidence to the moment it was sealed. They answer different questions.
Signed commits
GitHub verifies commits signed with GPG, SSH (the simplest to set up), or S/MIME and shows a "Verified" badge; vigilant mode marks unsigned commits. Sigstore's gitsign signs commits keylessly with your OIDC identity (GitHub login, for example), records them in the Rekor transparency log, and verifies with gitsign verify --certificate-identity=... --certificate-oidc-issuer=.... gitsign notes that GitHub does not yet recognise its signatures as verified.
What it proves: this commit was made by the holder of this key or identity. What it does not prove: why, what was tested, or that the pull request description is accurate.
Build attestations
SLSA defines attestations as an envelope (DSSE) around a statement with a subject (the artifact) and a predicate (what happened). GitHub Artifact Attestations produce SLSA Build Level 2 provenance for things built in Actions, signed through Sigstore (the public instance for public repositories, GitHub's instance for private ones), verified with gh attestation verify. Documentation surfaced in search suggests private-repository attestations need GitHub Enterprise Cloud; confirm against current docs before relying on it.
What it proves: this artifact came from this workflow at this commit. What it does not prove: anything about the human or agent decisions that produced the source.
A PatchArc capsule
A .parc is a ZIP with a canonical-JSON manifest listing every file's SHA-256, signed with Ed25519 by a key generated in the repository by patcharc init. It contains the deterministic six-section review, each observed commit's metadata and patch, the scope index, and your recorded decisions and risks. patcharc verify checks the signature and every hash offline; the cloud re-verifies before publishing an ArcLink.
What it proves: this review and this evidence are exactly what was sealed, by this key, at this time. What it does not prove: that the commits exist on your remote, that the decisions were wise, or who the person behind the key is (identity comes from the cloud account that uploaded it, not from the key). See Trust model.
Side by side
| Signed commit | Build attestation | PatchArc capsule | |
|---|---|---|---|
| Subject | One commit | One artifact | One Arc: a set of commits plus review |
| Signer | Author key or OIDC identity | CI system via Sigstore | Repository-local Ed25519 key |
| Transparency log | gitsign: Rekor; GitHub: none | Sigstore (public repos) | None |
| Verify offline | GPG/SSH yes; gitsign needs log access for full check | gh attestation verify needs the log | Yes, fully |
| Captures decisions and risks | No | No | Yes |
| Format | Git object signature | in-toto statement, DSSE | .parc (ZIP + canonical JSON); not an in-toto predicate |
| Identity binding | Strong | Strong (workflow identity) | Via cloud account, not the key |
How they combine
- Sign your commits (SSH keys are the easiest route to a Verified badge).
- Record the change as an Arc;
patcharc stopseals the review and the patches of those signed commits. - Build in CI and emit a provenance attestation for the artifact.
- Attach the ArcLink or capsule to the pull request; attach the attestation to the release.
A reviewer then has three verifiable facts: who authored each commit, what was built from them, and what the author understood and decided while making them.
What PatchArc should do next
A .parc is not an in-toto statement. Emitting a predicate that references the capsule's manifest hash would let gh attestation verify and SLSA tooling treat a review as supply-chain evidence. It is on the list; it is not in 0.2.0.
Frequently asked questions
Should I sign commits with GPG or SSH?
SSH is simplest to generate and GitHub verifies it; SSH keys do not expire, which is either convenient or a risk depending on your policy. GPG supports expiry and a web of trust. S/MIME requires a public CA.
Does a PatchArc capsule replace commit signing?
No. It signs the review and evidence, not the commits in your remote. Sign commits for authorship; seal capsules for the review record.
Is a .parc an SLSA attestation?
No. It is a signed ZIP with a canonical manifest. An in-toto predicate referencing it is planned.
Can I verify a capsule without PatchArc?
Yes. Canonicalise manifest.json (sorted keys, no whitespace), verify manifest.sig against it with the Ed25519 key in manifest.pub, then re-hash each listed file. See What is in a capsule.