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.

[ChristianCiach]

Related issue:

• Sanitize cosign's dependency tree #1462

[haydentherapper]

I'm supportive of this! A few thoughts:

• This verifier should be written based on sigstore-go and we should further prune dependencies there
• I think this verifier should be minimal in scope - support only artifacts and attestations.
  • For containers or other metadata that requires canonicalization (and large dependencies to calculate those hashes), we could support passing the hash for verification.
  • For verifying with KMS, we'll rely on KMS plugins.
• I'd like to avoid duplication between sigstore-go's example binary and Cosign. I think we could move the example verifier out from sigstore-go into Cosign, and use the same CLI flag language in Cosign for this new binary.
• For further duplication reduction, we likely can heavily rely on the new-trust-bundle verification codepath in Cosign

[steiza]

Just to follow up on this:

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 was overly optimistic on how much this would reduce the code size. Without a major refactor this could produce something that is more like 70 MB than 100 MB, but not near the ~15 MB of the sigstore-go example.