Feature: generate DSSE language clients from the protobuf

[kommendorkapten]

Last week I talked to both @SantiagoTorres and @adityasaky about the initiative in Sigstore to start to define all the data types in protobuf, for easier client implementation. Sigstore is relying on DSSE envelopes, and it would be nice if the code generation for DSSE was performed in this repository, and published to the canonical package repositories. The way go deals with packages I would think of the go code being generated in this repository, so clients could pull the package.

If this is something you think are worth doing, I'm ready to do the work, including updating https://github.com/secure-systems-lab/go-securesystemslib/blob/main/dsse/ with a new major release (this will be a breaking change) that utilizes the envelope struct from the generated code.

[MarkLodato]

Sounds good to me. Why is it a breaking change?

[kommendorkapten]

Hm I think I hear what you are saying, you would like for the protobuf generated code to be put in the same package as the dsse code is today? Then yes, it would not be a breaking change!

[MarkLodato]

Ah, I think there is some confusion about versions. There is the version of the spec itself, and the version of any libraries that implement the spec.

The spec itself is unaffected by this change. The protobuf describes the existing design.

Libraries that switch to protobuf-generated code from a custom interface might need to change.

[kommendorkapten]

Ah, I think there is some confusion about versions. There is the version of the spec itself, and the version of any libraries that implement the spec.

Correct, but if the build job that generates the code always pulls the protobuf from this repository we can manage that, by being explicit by the version we use.

Libraries that switch to protobuf-generated code from a custom interface might need to change.

I think this can actually be avoided. So if we instead update the go-securesystemslib package, to generate the code on build, and publish that code into the go-securesystemslib package, we won't get a breaking change, as the generated code will end up in the same package as the definitions is today.

This is not something I have done before (generate structs into an existing package), so I can't determine if it's a hack, or if it's a good solution :)