Add proto spec for a bundle

[cflewis]

It would be nice to have a proto spec for a bundle, along with the generated Go/Python bindings.

[TomHennen]

Do you mean this bundle?

If so I'm not sure it's possible to get protos to encode JSON Lines. Even if it were the various lines are supposed to be DSSEs and not the individual attestations.

Can you tell us more about what you're trying to do? It may have been discussed already.

[cflewis]

Yes, I do mean that bundle.

Please know that I am a complete newbie at this so I may have asked for something that is totally infeasible :)

The TL;DR is that it is nice to use the statements with native Go structures as it's ensures you're properly conforming to a schema (albeit the predicates are dynamically typed). Working with the bundle also as a native struct would ensure that, but also makes the code read cleaner: all the inputs and outputs are native and come from the same package.

[TomHennen]

Ok, just to be sure I understand,

What you're really after is an API that make it easy to work with bundles of in-toto attestations in both Go and Python. The bundle API doesn't need to be protobuf bindings per-se, but should be easy to work with when using protos to work with the attestations themselves. Does that sound right?

[cflewis]

Yes, that's right. It's not hard to do myself:

type Signature struct {
	KeyID string `json:"keyid"`
	Sig   string `json:"sig"`
}

// InToToBundle represents the attestation bundle.
type InTotoBundle struct {
	ContentType string      `json:"payloadType"`
	Payload     string      `json:"payload"`
	Signatures  []Signature `json:"signatures"`
}

The only thing about this is the bundle struct not part of the package where everything else is: spb "github.com/in-toto/attestation/go/v1" so the code isn't versioned alongside, and the bundle struct doesn't live in the same place where someone would expect it to be.

When I said "nice to have" I really mean it as such, I'm not blocked or anything. It's just a readability issue more than anything else 😄

[TomHennen]

I see, so I think what you're looking for is a library that makes working with in-toto bundles and statements easier. Probably something with Go bindings? And it doesn't need to be a protobuf per-se (I don't actually think it would be possible with protobuf)?

[TomHennen]

Oh, and one more thing, what you're calling an 'in-toto bundle' in the struct above is actually a DSSE. There is a protobuf for that, defined over in the DSSE repo https://github.com/secure-systems-lab/dsse/blob/master/envelope.proto

[adityasaky]

Note that it could be a non-DSSE envelope too, but by default it is DSSE. Also note that the DSSE spec provides the proto but implementations currently don't really use it.

[cflewis]

Oh, I see (I think 😉 ). If the DSSE spec could arrive as Go bindings in this repo, that would be nice.

[adityasaky]

https://github.com/secure-systems-lab/go-securesystemslib/tree/main/dsse is the DSSE implementation we're using in in-toto implementations and elsewhere for Go. FWIW, there's some work planned to streamline the Go libaries for in-toto specifically, so some of this may be in scope there.

[marcelamelara]

If the DSSE spec could arrive as Go bindings in this repo, that would be nice.

To clarify, because there's already a Go implementation of DSSE, I don't think we intend to import/replicate that spec here.

As @adityasaky mentioned, we're in the process of consolidating the various in-toto Go packages. The end goal will be that that consolidated Go package will both import the Go bindings in this repo and include the DSSE Go APIs. So that consolidated in-toto Go package would become your single unified API for using in-toto attestations in Go. We'll possibly be doing something similar for Python. Hope that helps clarify things!