Add attestation metadata analysis - #11
Conversation
steiza
left a comment
steiza
left a comment
There was a problem hiding this comment.
This is great!
I only had time to review 4. Data Format Analysis in detail, but I thought I'd leave some minor feedback / context.
|
|
||
| - **Data type**: JSON attestation bundles | ||
| - **Standard**: in-toto attestation format (https://in-toto.io/Statement/v0.1) | ||
| - **Provenance level**: SLSA v0.2 provenance predicates |
There was a problem hiding this comment.
Minor: it might be good to list here the supported predicates, like we do for PyPI below. The attestation API endpoint listed below returns two Sigstore bundles with different predicate types:
https://slsa.dev/provenance/v1(probably for more recent publishes - earlier ones might have been SLSA v0.2)https://github.com/npm/attestation/tree/main/specs/publish/v0.1which is similar in content to the PyPI Publish attestations, but different in stated purpose (this attestation is present on any npm publish that used provenance, which included several years before npm supported trusted publishing, so unlike PyPI it does not indicate trusted publishing was used).
The npm publish attestation is intended to be a public record independent of npmjs.com (since it appears in Sigstore's public good Rekor) that lists out exactly what a given package at a given version should contain. This makes it so that by compromising npmjs.com you can't modify what a previous releases contained, because you'd also at least need a way to forge a Rekor record with an inclusion proof from when the package was published. I hesitate to call this "immutability" by itself, but it does provide a much stronger integrity check of the package contents.
| - **Standard**: in-toto Attestation Framework | ||
| - **Supported predicates**: | ||
| - SLSA Provenance (v1.0 specification) - for build provenance claims | ||
| - PyPI Publish attestations (v1) - confirms publishing via Trusted Publisher (predicate type: `https://docs.pypi.org/attestations/publish/v1`) |
There was a problem hiding this comment.
It's not mentioned in PyPI's docs, but like I mentioned above for the npm publish attestation, one of the really valuable things this attestation does (in my opinion) is list out exactly what a specific package at a specific version contains, providing integrity checks that live outside of PyPI, which makes it much more tamper-resistant.
| - **Data type**: Sigstore bundles (`.sigstore.json` files) | ||
| - **Standard**: Sigstore bundle format | ||
| - **Provenance level**: Sigstore signatures supplement PGP signatures (both currently supported) | ||
| - **Signature format**: Sigstore signatures using Fulcio CA and Rekor transparency log |
There was a problem hiding this comment.
This is a really interesting one, because the Fulcio certificate contains in its OIDs enough information to construct a minimal SLSA provenance, but (as you note) the Sigstore bundle just contains a signature, not an in-toto statement with a predicate type like https://slsa.dev/provenance/v1.
| - `sigstore-ruby` gem (pure-Ruby implementation of Sigstore client spec) | ||
| - Command: `gem sigstore_cosign_verify_bundle` with certificate identity and OIDC issuer validation | ||
| - Third-party verification: DataDog's `go-attestations-verifier` library | ||
| - **Adoption tracking**: "Are We Attested Yet?" tracker at https://segiddins.github.io/are-we-attested-yet/ |
There was a problem hiding this comment.
Python also has adoption tracking - https://trailofbits.github.io/are-we-pep740-yet/ - that's what inspired this tracker!
|
|
||
| ### Java Ecosystem — Maven Central | ||
|
|
||
| **Attestation Information Available**: Yes, via Sigstore provenance (shipped August 2024) |
There was a problem hiding this comment.
Currently, there is no support for attestation, only Sigstore signatures are supported.
In-toto attestations could theoretically be published as additional artifacts (e.g. like in the Build your own SLSA 3+ provenance builder on GitHub Actions), but I didn't find any evidence of this method being actually used.
3 participants
Analysis of attestation and provenance support across npm, PyPI, Maven Central, RubyGems, Homebrew, and other package ecosystems.