Proposal to split the cosigned webhook to it's own repository.

[vaikas]

There's been a few times in the past where the point about splitting the cosigned webhook into its own repository has been brought up.

So, I wanted to formalize that a little bit and see how y'all are feeling about it and if that would be doable? I'd be happy to drive the mechanics of pulling apart the cosigned bits and importing into the new repo.

Pros I think are (some, not even close to all):

• Remove / reduce dependencies on k8s libraries in the main sigstore/cosign repo.
• Keep us more honest about the SDK aspect moving forward. Point I'm trying to make that by making sure the interfaces between the 'core' cosign APIs are now reusable by two different repos will make it clearer where the boundaries of SDK are, vs. just public functions in the repo that are callable. Hope that makes sense.

I think on the con side there's obvs the initial grunt work on pulling things apart, but I think in the longer term it will be cleaner to split the webhook into it's own repo with its own maintainers, release cadence, etc.

Thoughts?
@bobcallaway @dlorenc @lukehinds

[imjasonh]

Related: sigstore/cosign#1462

[dlorenc]

I'm fine either way here.

[lukehinds]

sounds OK to me. One thing if possible, when re-factoring out code (if it makes sense), it would be good to utilise sigstore/sigstore.

[lukehinds]

also kudos for using the this repo to ask! we should try to keep this working context going forward, as its then a recorded decision (and not lost when slack purges messages).

[lukehinds]

Last one: I think a name change would be beneficial, and the code move would be a good opportunity to do that. It's very easy to mistake cosigned as a cosign (vice versa), when spoken out loud.

[vaikas]

That's facts about cosign/cosigned being easily confused when spoken out lout. Mayhaps to explicity spell it out the repo could be something like:
cosigned-webhook
cosign-webhook
cosign-admission-controller

But I should not be counted on to come up with a good name :)

[dlorenc]

I like the last one.

[vaikas]

@bobcallaway what are your thoughts?

[dlorenc]

Have you figured out how to do the split? It's always a bit tricky when you try to preserve history.

[vaikas]

I hadn't thought about the history, naively thought the history would live in sigstore/cosign prior to the move and stay there. I'm totes open to suggestions on doing the right thing, I just don't know what it is.

[dlorenc]

I think there's a git filter-tree thingy, but that's fine too

[bobcallaway]

+1 to this idea, as well as to luke's reminder about sigstore/sigstore

[elfotografo007]

+1

[hectorj2f]

The main historical reason aimed to keep the dependencies together. That could ease the maintenance and testing of cosigned.

This is also related to sigstore/cosign#651

[vaikas]

Do folks have any major objections for the repo being:
sigstore/cosign-admission-controller

Certainly very descriptive :)

[hectorj2f]

I am certainly not good at naming things, I am happy with any name better than X Æ A-12.

e.g. sigstore/cosign-policy-controller in case things evolve in the future.

[adamd-vmw]

I like either of those two options.

[dlorenc]

Either works for me.

[adamd-vmw]

also could consider sigstore-policy-controller or sigstore-admission-controller

thoughts?

[imjasonh]

also could consider sigstore-policy-controller or sigstore-admission-controller

thoughts?

If it's under the sigstore org I'd say you could avoid some stutter if you just call it sigstore/policy-controller etc.

[adamd-vmw]

One other note, for our purposes, it would really help if we can finish the bump to v1beta1 before splitting out the repo, and also come to a decision on the package name as soon as we can.

[lukehinds]

also could consider sigstore-policy-controller or sigstore-admission-controller
thoughts?

If it's under the sigstore org I'd say you could avoid some stutter if you just call it sigstore/policy-controller etc.

That's sounds good to me, has my +1

[hectorj2f]

I believe we have a winner sigstore/policy-controller :) here.

[lukehinds]

approved: repo name: sigstore/policy-controller