Should ratify continue support for cosign

[susanshi]

We had a few items related to bug fixes needed for cosign and ideally separating cosign from oras store. There has been some feedback that there are not too many verifiers that work with Cosign on K8s and it will be good to keep it healthy. We haven't been prioritizing cosign code path in the current milestone, starting a discussion here to discuss how we should support cosign going forward.

[sozercan]

+1 on supporting sigstore/cosign since this is one of the differentiating features for ratify.

I don't believe there are any tests for cosign today. I think it would help if there were tests so implementation doesn't break.

[sajayantony]

+1 to continue support. /cc @lachie83 @luisdlp

[akashsinghal]

Here's a bit of context on the current state of cosign in Ratify:

In general, the current support of cosign is quite limited and very "hacky". Currently, a plugin-based cosign verifier is implemented here. The cosign verifier actually processes the subject reference passed in and cosign handles all of the pulling and verifying of the signature. This breaks Ratify's current abstractions. The Referrer Store is responsible for pulling all artifact contents (this includes any auth providers needed to authenticate to registry) and the Verifier is supposed to only be responsible for the verification operation. The ORAS store has multiple auth providers it can use to get the credentials for the registry. But since the verifier is doing the pull here, it has no access to the registry creds which means there is no auth possible. This is why cosign signatures cannot be verified from private registries.

In the core execution loop, the verifiers are invoked for each referrer artifact found attached to a subject image. Since cosign does not support ORAS artifacts, the ORAS store's `ListReferrers' implementation will not apply to cosign signatures. To get around this, we currently have some helper methods that utilize CRANE to pull the cosign signature tagged OCI manifest and repackage it into an artifact descriptor that can be added to the list of referrers. Ideally, since cosign has a completely different way of pulling referrers, we should have a separate cosign store.

[sajayantony]

Once cosign moves to the OCI spec I think this will become consistent. There is good amount of everyone converging to pull stuff in the same way. I think clarifying how cosign can use the creds for the registry would help this discussion.

[akashsinghal]

Yes agreed. Once they converge, notation and cosign can both leverage the ORAS store implementation without us having to special case cosign. The other piece to this is figuring out how to leverage cosign's local verification scenario. This will allow us to just pass in the signature contents to cosign. This is a very similar issue to what we will face when we have to upgrade our notation-go version which has built in signature pulling in the verification process now.

How does cosign currently handle registry creds?
Current implementation has 2 spots which require auth. In the ORAS store we use CRANE to pull the cosign signature and add it to the list of referrers. Here we would need to provide the same credentials we gathered from the auth provider (this shouldn't be a problem since this is in the ORAS store). The other path is in the verifier where cosign itself needs the credentials to the registry passed since it performs the pulling. The verifier has no good way to access the credentials in the store.

What about non-referrers enabled registries?
Currently, if a registry that does not have referrers API is used, the verification process will fail even if only the cosign verifier is configured. Previously we had special exception handling to catch if a registry returned a 404 and cosign was enabled. This was accidentally removed when we upgraded to ORAS go v2. We can add this back to unblock this scenario but again it's not ideal to have the ORAS store doing this.

Here are some options to address issues in the interim:

1. We take Susan's fix (Chart updates to allow cosign and notary verifier to be configured together #382) which should unblock the current cosign flow. This will still mean only public registries will work with cosign.
2. We take Susan's fix and then figure out how to use cosign's local verification functionality. We would then add a new special case in the GetReferenceManifest of ORAS store to return the cosign manifest when requested.

[dtzar]

We're already moving forward with option 1. Considering as Sajay mentions it is stated cosign plans to eventually move forward with OCI implementation, I don't think we should do option 2.

That said - I do believe it would be worthwhile to file an issue with cosign regarding the authentication model not being able to utilize on-cluster credentials.

[sajayantony]

#381 (comment)