sigstore / protobuf-specs

Protocol Buffer specifications
Apache License 2.0
23 stars 29 forks source link

Converter for newer bundle versions #204

Open haydentherapper opened 9 months ago

haydentherapper commented 9 months ago

We've got a lot of bundle versions floating out there. Well, really just two. But soon, there will be three!

What do y'all thinking about a CLI to "upgrade" a bundle to the latest version? The converter would need to understand the breaking changes between each version to resolve them (and prompt users when the change could not be automatically resolved, but I don't think we have this need currently). Roughly, this would include:

This converter could also be used by package repositories that are persisting Sigstore bundles to keep bundles "fresh". We'll need a converter per-language then. Initially I was planning to throw one together just as a CLI.

Thoughts @woodruffw @bdehamer @loosebazooka @steiza?

kommendorkapten commented 9 months ago

At least providing clear documentation on how to upgrade would be a good start.

If this where built in a cli, where would such a cli live?

loosebazooka commented 9 months ago

Pretty sure we would not be able to edit maven central bundles.

I think the java client would just have to contain parsing logic for all supported bundle types. v2 -> vX

woodruffw commented 9 months ago

I like the idea of a CLI to start! Fully agreed with the rationale 🙂

steiza commented 9 months ago

Generally makes sense to me.

We'll need a converter per-language then.

Maybe - I think it depends on if we're upgrading bundles on-the-fly or at rest. If we're doing one-off bundle format migration for data at rest, I don't know that we'd need a per-language tool to do so.

haydentherapper commented 9 months ago

If this where built in a cli, where would such a cli live?

Either in this repo, or in the repo that matches the language this was built in (so probably sigstore-go?)

Pretty sure we would not be able to edit maven central bundles.

Yea, this isn't a requirement for package registries, just an option if they want to keep up with the latest bundle format. Just curious, is there a specific reason why in this case? Just lacking support?

Maybe - I think it depends on if we're upgrading bundles on-the-fly or at rest

Agreed, up to the registries if they want on the fly upgrades.

Thanks all!

codysoyland commented 3 months ago

I wrote this: https://github.com/codysoyland/sigstore-bundle-upgrade

I can make this a PR to sigstore-go if that makes sense.