Clarification on sget functionality

[lukehinds]

To help frame what sgets role will be;

sget will be used as a replacement for curl type operations that pull in untrusted content and then proceed to execute.

A few examples:

curl -Os https://uploader.codecov.io/latest/linux/codecov

chmod +x codecov
./codecov -t ${CODECOV_TOKEN}

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"

sget will remediate the risks by allowing maintainers to sign their blob / script and then have it verified on retrieval

This will then allow users to perform a simple one line operation such as

sget <artifact>

As a lot of these operations can occur in an unattended manor, sget will have a batteries included simple policy system.

This will be in two forms initially

1. a cosign style TUF policy
2. A remixed play on SSH allowed_signers (thereby allowing folks to use existing keys likely already stored in the repository providers service (e.g https://github.com/lukehinds.keys )

I will continue to flesh this issue out, but its also worth looking at the original proposal doc

https://docs.google.com/document/d/12BBOXMhA99J3KzNaotT1J4OTSDlNnK110_9FZkPv-A0

[dlorenc]

I see in #57 it looks like sget is starting to grow key management/signing functionality. What's the full scope there?

I'm worried we might run into overlap/confusion between the tooling for users, as well as more stuff to maintain.

[lukehinds]

I don't see any issue myself, sget is a client , as is cosign and the other clients, with each being able to generate keys and sign things. In regards to maintenance there is a group of 4 engineers willing to do that work.

[imjasonh]

Would it help to have some kind of cross-project e2e test that ensures that keys generated with cosign can be used to verify using sget, and vice versa?

If we end up having N different tools (really, the problem will be N different libraries/languages), we'll have a combinatorial explosion of tests, but it's not so bad while N=2 (or N=3).

[lukehinds]

There is code in sigstore-rs to load a cosign pub key and verify. What we have to figure out is getting a cosign generated private key to sign within this code base as I am not having any luck getting the secret box parts working and we need a key to sign with for #74 that @jyotsna-penumaka now has working well. I would prefer the keys be interchangeable and will try again to get it working. it might be possible with the ring library. If not we might just need to stick to the idiomatic approach there is in rust.

[dlorenc]

I don't see any issue myself, sget is a client , as is cosign and the other clients, with each being able to generate keys and sign things. In regards to maintenance there is a group of 4 engineers willing to do that work.

I guess I'm just still confused at the scope and eventual plan.

Initially sget started as just a lightweight verifier. If we add signing to it as well, how would we explain whether to use sget or cosign or something else to an end user? Which audience do you see using this tool?

[lukehinds]

Initially sget started as just a lightweight verifier. If we add signing to it as well, how would we explain whether to use sget or cosign or something else to an end user? Which audience do you see using this tool?

As I understand it cosign is for signing things in an OCI registry. For sget the signing element will be for signing within non OCI storage (git right now as per #74). There are no plans to make sget into a container signing tool, if that is the concern.

[dlorenc]

No real concern about the cosign scope, I just worry that we have two things that do the same thing still, with the only real difference being the implementation language. The doc linked above doesn't really mention signing at all, only verification: https://docs.google.com/document/d/12BBOXMhA99J3KzNaotT1J4OTSDlNnK110_9FZkPv-A0/edit#heading=h.pw2szigdbarp

Am I missing something?

Cosign also kind of supports signing generic blobs right now, which is where I see the overlap.

[lukehinds]

sure, but it signs blobs in an OCI registry, as said we don't plan to do that. We need a key to sign artifacts in a git environment.

[dlorenc]

No sorry! It signs blobs outside of them too: cosign sign-blob

[lukehinds]

to local disk right?

[lukehinds]

One thing I expect we could do to really cement the differences is drop all the OCI elements from sget. sget and cosign then use different storage backends. I will float the idea with others working on sget. That should then make things clearer and less prone to confusion.

How does that sound?

[dlorenc]

Yea - cosign sign-blob supports signing arbitary blobs and outputting to stdout or local disk. I'm still not super keen on having two tools that do the same thing here - is there a real user need for "cosign but without OCI"?

I'd really love for there to be a lightweight verification tool that doesn't support signing or key management at all, since the majority of users will be downloading packages rather than building/signing them. I'm not trying to limit the scope of sget or anything here - I just really want to have something that supports only verification, and that's the direction I thought we were going to go with sget.

[lukehinds]

"is there a real user need for "cosign but without OCI"?" I mean I could ask the same about cosign/sget? :)

Anyway I feel we are going in circles a bit here. I am happy to propose we remove OCI interaction to help set boundaries, but I don't think it's fair to expect only a single client be capable of key generation and signing things. I think we should also look again at what I proposed before (on the rust side) and consider a name change to further help bolster separation.

[dlorenc]

Anyway I feel we are going in circles a bit here. I am happy to propose we remove OCI interaction to help set boundaries, but I don't think it's fair to expect only a single client be capable of key generation and signing things.

I agree - I think we might want to just step back and figure out what the gaps are and then make sure we're filling them. At a high level I have two concerns here:

• Overlap between tools could lead to user confusion unless we can clearly explain the rationale. I don't think I can clearly explain the rationale for having overlap now, or what the overall end goal is for sget
• I think there is a missing piece with a lightweight verify-only tool, so I want to make sure we have a place to get started on that. Even if we do decide to go forward with sget signing things, I want to make sure we get a place for the verify-only tool.