Add Pacto and Pacto Evidence material types

Ouverte
  • Quelque chose ne va pas ?
#3,367 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
42/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Calme
Stack technique
go
Domaine
backend

Piste de recherche

Start by reading Chainloop's material types documentation and locating the existing material type definitions and CAS handling entry points; the issue does not name specific files or tests. Check how native types are registered and validated, then identify the changes and tests needed to accept Pacto contract and evidence OCI artifacts and expose their metadata. Done means both types work with existing material/CAS mechanisms and their proposed metadata is available.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

component/artifact-cas Feature integrations

Hola Chainloop team!

A short update to this proposal for native Pacto material types. Since I opened it, Pacto produces a third artifact worth adding.

What is Pacto?

Pacto is an open-source operational contract system for cloud-native services: each service gets one YAML contract, versioned and distributed as an OCI artifact in the registry you already run. An optional delivery layer picks which version runs in each environment while Flux or Argo CD applies it (delivery is Alpha today).

pactoVersion: "2.1"

service:
  name: payments
  version: 2.4.0
  owner:
    team: payments

dependencies:
  - name: ledger
    ref: oci://ghcr.io/acme/pacto/ledger
    compatibility: "^4.0.0"
    required: true

checks:
  - name: smoke
    file: evals/smoke.yaml
Proposed material types

PACTO: a Pacto contract bundle (an OCI artifact). Expose:

  • service name and version
  • owner
  • Pacto version (2.0 or 2.1)
  • digest

PACTO_EVIDENCE: runtime evidence. A producer signs an evidence envelope (Ed25519) and pushes it to the Pacto Evidence Server, which checks the signature, evaluates the evidence against the contract and stores the result as an OCI 1.1 referrer of the exact contract revision. Artifact type application/vnd.pacto.evidence.record.v1+json, payload schema pacto.dev/evidence-record/v1. Expose:

  • contract digest (always an immutable oci://...@sha256:... reference)
  • producer id and key id
  • observation timestamp, plus the envelope's issuedAt and expiresAt
  • Pacto's compliance verdict and findings
  • evidence digest

PACTO_DELIVERY_RECORD (new): when delivery runs with its recorder enabled, every change that ends (refusals included) gets a signed record of what was asked, by whom, what each check said, who approved and how it ended. It is a Sigstore bundle (application/vnd.dev.sigstore.bundle.v0.3+json) holding a DSSE envelope over an in-toto Statement v1 with predicate type delivery.pacto.trianalab.io/operation/v1, attached as an OCI referrer. Verify it against a configured recorder identity, then expose:

  • subjects to and from (the version digests after and before), contract and anchor (the Stage's stream)
  • actor.user and actor.class (human, agent, break-glass or controller)
  • approvals[] and verdicts[] (each check's result: Pass, Fail or Unknown)
  • outcome.result and outcome.verification (Verified, AcceptedUnknown or Unverified)
  • guarded: true when the cluster's admission policies confirmed who asked and who approved

Limits: records exist only when the recorder is turned on, they need a registry with the native OCI Referrers API (GHCR and distribution do not have it) and they are not sent to a transparency log such as Rekor.

Why Chainloop?

A release could carry all three next to the usual materials, linked by digest:

flowchart TD
    R[Release] --> I[Container Image]
    R --> S[SBOM]
    R --> P[Provenance]
    R --> C[PACTO]
    R --> E[PACTO_EVIDENCE]
    R --> D[PACTO_DELIVERY_RECORD]

Chainloop could then apply policies such as:

  • the PACTO_EVIDENCE contract digest must match the PACTO material in the same attestation, and the evidence must not be stale;
  • a production release must contain a delivery record whose to subject is the version it ships and whose outcome.result is Succeeded;
  • the record must verify against a trusted recorder identity, and guarded must be true.

Pacto stays responsible for interpreting contracts and evidence and producing its own findings and decisions.

Proposed first step

Add PACTO and PACTO_EVIDENCE as content-addressed materials handled through Chainloop's existing material and CAS mechanisms, exposing the fields above. PACTO_DELIVERY_RECORD can follow; it is already in-toto in a Sigstore bundle, a format Chainloop knows. The generic EVIDENCE type could technically carry all of this, but each artifact has a defined format and semantics, and the digest links between them are the important part.

References

Happy to contribute the Pacto side and work with the Chainloop team on the implementation.

Langage dominant
Go
Étoiles
582
Forks
61
Merge moyen
12 h 47 min
PR mergées (30 j)
137

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de chainloop-dev/chainloop

Toutes les issues de chainloop-dev/chainloop

Issues similaires

Plus d'issues Go

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.