Jason Hall

`kubectl plz apply -f https://.../deployment.yaml`

+1 from me, and seemingly overlaps with some of the thinking in https://github.com/sigstore/sget/issues/44#issuecomment-995658840 -- tl;dr: requiring the script to be in a registry will be a barrier to adoption for...

So the general idea is that `cosign policy init` would write _only_ the policy (maintainers, threshold) to an OCI registry, then `cosign policy sign` would effectively become `cosign sign reg.io/policy@digest`,...

> Would this mean we lose the previous sigs? Nope, when a policy changes the previous sigs would still be present at `reg.io/policy:.sig`, and the previous policy content would be...

A totally reasonable question! (At least, to me, someone who may also need to learn more about how these policies work) AIUI the `previousRoot` isn't intended to replace the need...

Yeah, I think we should walk through the overlap with `cosign upload-blob` and `cosign sign-blob` -- is the blob we're signing the script.sh? Or the policy for script.sh? When the...

It's hard to argue with the existing UX's ease of use. I also wonder if requiring maintainers to copy it to some registry is just going to be too high...

Nice! [The GitHub Contents API](https://docs.github.com/en/rest/reference/repos#contents) and [GitLab's Repo Contents API](https://docs.gitlab.com/ee/api/repository_files.html#get-file-from-repository) both assume the default branch, and in both cases you can set it with `?ref=v1.2.3`, `?ref=`, etc. What's the flow...

Yeah my question was (poorly-elaborated), how do we make sure the signature changes end up in the same commit as changes to the signed file(s). Having them in separate commits...

This might let us drop our code for handling ID tokens passed directly: https://github.com/sigstore/sget/blob/3e9f15c194f6698d8040d3d1771df0272d38de51/sign.go#L65 And replace it with the [`filesystem` provider](https://pkg.go.dev/github.com/sigstore/cosign/pkg/providers/filesystem), which expects the ID token in a standard path.