VSA: file extension recommendation

[laurentsimon]

Is there a particular file extension recommended for VSAs?

[TomHennen]

IMO VSAs are just any other attestation and, if stored in a file, should go in an in-toto Bundle with any other relevant attestations. So maybe .intoto.jsonl ?

[laurentsimon]

So if someone produces both VSA and provenance, would you call the files package-v1.2.3-provenance.intoto.jsonl and package-v1.2.3-vsa.intoto.jsonl, for example?

[TomHennen]

If someone produces a VSA and provenance they should both go in one file named package-v1.2.3.intoto.jsonl. A verifier can look through all the attestations in that file and use whichever they need.

[edit] Or is there a good reason to keep them in separate files?

[laurentsimon]

I see a few arguments in favor:

• Separate file is simpler for human to look at and simplifies verification too. Instead of iterating over all attestations, verifier can immediately process the relevant one.
• UX: simpler for maintainers who get a VSA and want to just add it to their list of attestations, without the need to understand the underlying format. We could ask them to cat vsa >> <>.intoto.jsonl, but that's yet an additional step. For example, the provenance from GCP is an intoto statement with additional metadata, it's not pure intoto. Users would need to retrieve the underlying intoto statement themselves; unless GCP provides a new API to retrieve the "raw" intoto.
• race condition: as soon as you add data to an existing file, there are race conditions to be aware of. If multiple entities are trying to append to the same file, you need a way to serialize the access. In GitHub, if you run a strategy matrix, this sitution happens.

I don't know if these are good reasons :)

[TomHennen]

The big problem is that the producer of the attestations are often distributed over the entire supply chain and are often a few steps away from the verifier. That means that every step along the way needs to know which things to propagate. If each attestation lives in a different file you wind up having to move N files for each artifact which is cumbersome and also prone to missing new things.

For example, the provenance from GCP is an intoto statement with additional metadatas

IIUC you can assemble a properly formatted self-contained DSSE from GCB, and that's what should be stuck in this file. Though I think they only make this available via the Container Analysis API at the moment and it does require some futzing with things. IMO that's a usability problem with GCB, downstream consumers of the artifact shouldn't need to support GCB's special way of doing things, so much better to encode it in a DSSE and propagate in one consistent manner.

[ramonpetgrave64]

Since the VSAs have a section for inputAttestations, I don't think it particularly needs to be a jsonl.

As for slsa-verifier, we have a draft implementation of verifying VSAs: it's fine, so long as it's a single json object. So far the VSAs produced by Google do use jsonl, but are a single DSSE envelope, though no contained inputAttestations yet.