finch icon indicating copy to clipboard operation
finch copied to clipboard

Expose cosign CLI via Finch

Open sam-berning opened this issue 2 years ago • 2 comments

What is the problem you're trying to solve?. As of https://github.com/runfinch/finch/commit/84c2634b7c1226ba9746d0cda4d22ec571454160, the Finch OS image includes Cosign by default to support signing container images. However, if a user wants to generate a keypair with Cosign they either need to install Cosign on their Mac or they need to SSH to the VM.

Installing a separate Cosign binary on Mac can cause issues with backwards compatibility in cases like the upgrade from v2.0.0 -> v2.0.1, where the default PEM label was changed to a label that v2.0.0 did not recognize. So if a user had v2.0.1 on their Mac and v2.0.0 on their Finch VM they could not use the generated keypairs to sign an image.

Describe the feature you'd like A new CLI command in Finch e.g. finch cosign which exposes the cosign CLI to allow users to generate a keypair with the version of cosign already installed in the Finch VM.

sam-berning avatar Apr 17 '23 21:04 sam-berning

IMO, adding a new command specifically for cosign is a slippery slope. There will likely be other tools installed in Finch's VM in the future, and I doubt we want to specially expose every single tool individually when they are added.

The Cosign issue is interesting, in that it was a micro/patch version that apparently had a breaking/backwards-incompatible change. I think this will be rare in general, but if we want to fix the issue with Cosign specifically, we can contribute to the Cosign project to add flags/environment variables to specify which type of key should be generated / used for verification.

If we really want to expose the tools inside the VM to the mac, maybe the right approach is to add a more general finch shell command, which wraps the similar limactl shell command?

pendo324 avatar Apr 17 '23 23:04 pendo324

IMO, adding a new command specifically for cosign is a slippery slope. There will likely be other tools installed in Finch's VM in the future, and I doubt we want to specially expose every single tool individually when they are added.

This is a fair point, but just because we add CLI support for one tool doesn't mean we always need to in the future. I think Cosign might also just happen to be one of the exceptional cases where we want it.

Having Cosign pre-installed on the VM creates a bit of an odd user experience in that finch push --sign cosign works out of the box, but in order to use it you probably want to generate a key, and for that you need to download the Cosign CLI locally. This isn't too weird on its own, but say you want to use Notation instead -- you can download Notation on your Mac, but finch push --sign notation won't work.

Because of this, I feel it makes more sense to be up front with users that, "hey, we're packaging Cosign with Finch, and that's why this works". And if we're doing that, it feels a little silly to require users to download Cosign again in order to generate a keypair.

I think adding a first-class CLI to command for Cosign helps on both fronts: it helps advertise that Cosign is packaged with Finch, and it allows users to more easily use the version of Cosign that's already installed on their machine.

If we really want to expose the tools inside the VM to the mac, maybe the right approach is to add a more general finch shell command, which wraps the similar limactl shell command?

I like this option as well, it's less work in the long run (both in adding future commands and maintaining the Cosign commands). As I said above, I like that finch cosign advertises that Cosign is packaged with the VM, but we can document that in other ways.

One thing that's a little funky with this option is that it confuses the scope of the CLI a little with finch and finch shell nerdctl being functionally identical. I'd almost prefer a separate binary for this (e.g. finch-shell cosign). WDYT?

sam-berning avatar Apr 18 '23 01:04 sam-berning