Smaller cosign-verify binary

[steiza]

Description

The compiled cosign binary is quite large (~100 MB) and unlikely to get dramatically smaller in the near term. Part of this is due to the flexibility of cosign, in the number of different ways you can sign content, which our users appreciate.

But at the same time, ecosystems adopting Sigstore might want a smaller, self-contained, utility specifically for verifying Sigstore content. This repository could produce a smaller binary, named something like cosign-verify, that just handles the verification commands cosign supports, and hopefully would be an order of magnitude smaller (~10 MB).

[codysoyland]

Is the primary goal to make a smaller binary? I wonder if the work being done in sigstore/sigstore#1901 for making KMS providers pluggable could reduce it substantially, or we there are other means to reducing cosign's binary size.

Would it try to mirror the verification commands/flags that exist in cosign today, or would verification be rewritten to solely use sigstore-go and simplify the flags?

If this is a simplified rewrite, I worry how much this overlaps/conflicts with the idea of migrating the cosign commands to support trustedroots/bundles natively and deprecating existing functionality. This proposal could be the start of a "rewrite" of cosign, and I worry a bit about fragmentation when maintaining two command sets with overlapping functionality.

I'm definitely in favor of having a cosign verifier that is much smaller, and perhaps a rewrite is the right answer, but I want to understand how this fits into cosign's strategy and if we could accomplish the same goals while improving the overall cosign codebase.

[steiza]

Yes, so if we did this we would definitely want to do it in a way that was minimally disruptive to the cosign codebase and this would definitely not be a rewrite.

I haven't been thinking about this for very long, but for example, what if we split out the way we add subcommands to cosign into verifier and non-verifier parts? cosign would still do both, but then we'd have a codepath for a cosign-verify command that has the same API, but reduced functionality and (hopefully if the go compiler's dead code detection is good) a much smaller footprint on disk.

I'm not committing to that exact implementation strategy (I want to think about it more) but that's an example of how we could achieve this without a lot of work upfront or maintenance work in the future.

[codysoyland]

It would definitely be interesting to see how far we can get with only a minor refactor and deadcode detection. If it used the same codebase, that would be a huge win for maintainability.