Include SLSA provenance protobuf with in-toto attestation language bindings

[marcelamelara]

In an effort to enable broader adoption of the in-toto attestation spec, we now provide protobuf definitions for the spec and predicates and corresponding pre-generated language bindings.

For the SLSA provenance predicate, we would like to include it in the pre-generated language bindings used across all in-toto implementations, but also avoid duplicating work and sync'ing issues given that this repo already provides a .proto definition for the predicate.

So, we are trying to figure out what the best way is to add support for SLSA provenance via the in-toto attestation language bindings. Are there any plans to generate language bindings for the provenance.proto definition in this repo? Alternatively, would it make sense to point to the .proto definition in this repo when the language bindings are built over at in-toto/attestation?

Other ideas?

[joshuagl]

We do not plan to generate bindings from this repo. If we can use the .proto here to generate code in the in-toto attestations repository, that's great. However, I think of the protobuf definition in this repository as pedagogical and demonstrative, rather than a canonical definition to use for code generation. The priorities are different and therefore we may not want to bind the two use-cases together with a shared definition?

It would be good to hear from others who are more familiar with protobuf.

[MarkLodato]

I think the simplest solution is to copy the proto from the SLSA repo into the in-toto repo. We don't make changes to it very often, so that shouldn't be difficult to keep it in sync. You could optionally use git subtree to automate the merges.

[marcelamelara]

Thanks @MarkLodato and @joshuagl ! Copying the proto over works for us, mostly wanted to make sure that wouldn't cause any issues/conflicts from the SLSA end.