[UI/UX support for attestations] Community feedback wanted: what will package attestations look like in the future?

[nlhkabu]

I am opening this ticket to ask the community for feedback on what they anticipate package attestations will look like in the future.

In #75, I learned/documented that:

1. In the future, more predicate types may emerge, as different organisations or users choose to verify packages for their own purposes
2. In the future, established/existing predicate types will publish new versions (e.g. SLSA versioning)
3. the npm Publish predicate will most probably be updated to include information about the trusted publisher and build workflow once npm lands support for OIDC - see [UI/UX support for attestations] Audit Supported Attestation Types #75 (comment)

So, my questions:

What type or organisation or user would create new attestation predicates?

I can imagine scenarios where:

1. an existing package repository (e.g. https://crates.io/) creates its own predicate
2. a new package repository emerges and creates its own predicate

What other scenarios could exist / should we be aware of?
Would third parties (e.g. security tools or organisations) create attestations? Why? What might these look like?
Would individuals create attestations? Why? What might these looks like?

How might existing predicates evolve over time?

I can see that SLSA has just announced its v1.2 release candidate.
How might this (and other predicates) change over time?

How will package repositories choose to adopt different predicates?

Right now, RubyGems does not support SLSA predicates - is there a plan to adopt (and display) SLSA predicates in the future?

If a third party created a new predicate type, how would software repositories assess whether or not to support it?

[colek42]

We have a pluggable system for creating attestation types in witness, let me know if I can help. ref: https://github.com/in-toto/go-witness/tree/main/attestation

[nlhkabu]

See pypi/warehouse#18007 for PyPI publish attestations from email identities

[steiza]

Yeah, the attestations are confusing. I think the place to start is with "what problem are we trying to solve" and then map that to the predicate(s) in use.

Essentially there's two questions a repository is trying to help users solve with attestations:

1. Given this artifact, link me back to the source code, build instructions, and build logs associated with it
2. Tell me authoritatively what artifacts are part of a given release name and a given release version

npm was first out of the gate, and chose SLSA Provenance for (1) and the npm publish attestation for (2). Later PyPI came along and realized that if they had a Sigstore bundle with a PyPI publish attestation they could cover (1) with the Fulcio certificate in the Sigstore bundle and they could cover (2) with the PyPI publish attestation - clever!

Note that there's several ways you can do (2) without an attestation, like the RSTUF project that's part of this working group.

To me, the exact in-toto predicate type that a repository uses to provide (1) or (2) doesn't matter much - as long as they provide some capability for each of those items. In most cases, I'd expect the repository CLI (npm, pip/uv, cargo) to be the one that handles the details of whatever in-toto predicate that ecosystem chooses.

[nlhkabu]

Thanks very much for this context @steiza

I guess the challenge then is to help people understand the difference between 1 and 2, and display this appropriately for when a package has 1+2, 1 only or 2 only.

re: the potential for third party attestations (something @di mentioned in a chat thread) - would we expect these to always fall into category 1 + 2? Is there any other scenario where third parties would want to attest something different?

[steiza]

Third-party attestations could be anything! Maybe the most common would be a signed SBOM, but some people are also experimenting with attesting to code review, that there were no known vulnerabilities at build time, or that static/linter checks passed before the build.

It might be interesting to hear about if people are using additional third-party attestations, and to what end, but today package repos are focused on answering the 2 questions I listed in the previous comment.