Guidance on use with JWT

[ChevronTango]

I know there's been a fair amount of work on gitlab integration and cicd which is great, but I'd like to know if there's anything that can be configured if I can retrieve a JWT token myself?

I have a lot of users on dev stations I configure for them. I also have the ability to retrieve a JWT for each of them (aud: sigstore) from the command line. Is it possible for me to setup their workstations to sign all of their commits using a (private) sistore cert? Can I pass this JWT to fulcio automatically without needing to do any browser based auth manually, like cicd pipelines do? And can I automate this so all my users get this benefit without needing to do anything manually themselves?

[ChevronTango]

So I dug around in some more comments and found that setting SIGSTORE_ID_TOKEN is what I need to do, but It would be useful to have more guidance on this.

[wlynch]

Hi! Sorry I missed this (was out at a conference last week).

It's complicated 😅

Short answer is we avoid it because we don't want to store long lived auth credentials - https://github.com/sigstore/gitsign#is-there-any-way-to-bypass-the-browser-flow

Long answer is Sigstore doesn't actually care where the JWT comes from, so long as it's from a valid issuer it recognizes (see https://github.com/sigstore/fulcio/blob/main/config/fulcio-config.yaml for the public instance Fulcio config) with the right audience. The web flow is a Sigstore-provided oauth flow that lets you get JWTs on demand. If you had a long lived refresh/access token you could exchange this for a JWT without the browser, then use that to get a Fulcio cert.

However, the downside here is those creds are another long-lived credential you need to protect - anyone who has your token could fetch tokens/certs as you. One of the goals for gitsign is to not rely on long lived credentials so we've been very hesitant to recommend this. The browser pop-up is a trade-off so that the only credential that needs to be worried about is your browser's cookie cache.

There have been a few ideas we've toyed around with, but haven't put serious effort into yet:

1. Extend the credential cache to store auth tokens for their whole lifetime, not just the lifetime of the cert.
2. Allow for tokens to be retrieved by credential helpers similar to git/docker cred helpers - i.e. shell out to some binary (gcloud, gh cli, etc) that knows how to get JWTs and delegate the trust decision for how long and how to store tokens to individual tools.
3. See if there's a way to hook into a browser's cookie cache and make the request using local cookies without a browser window (we don't know enough about how cookies work to know if this is feasible).

[ChevronTango]

Thanks. So I have the ability within the environment (gitpod) I'm looking at to generate temporary short live JWT tokens from the command line. They aren't long lived and also not stored on disk as I can pass them through to gitsign and fulcio directly without persisting anything to disk. I agree that long lived tokens go against the intention of gitsign but I believe the system I'm working with avoids that issue nicely. My main question was whether I could use the CLI to pass this token to gitsign directly, and I believe with the SIGSTORE_ID_TOKEN I can (and have now proven in testing) bypass the browser auth flow and achieve exactly what I wanted.

If you are curious, I created a new shell script to wrap gitsign and as part of that script, generate and pass in the token to gitsign. I then configure git.config to use my script rather than gitsign directly. The end result is a gitsign utility that doesn't require any browser auth and works every time.

[wlynch]

Yeah for Gitpod and other cloud workspaces that feels reasonable to use, since these tokens would be provisioned and managed by the service provider.

Hooking into a CLI sounds inline with the credential helper approach. 🙂 If you're interested, I don't think it would be that much work to add a new credential helper config option to Gitsign. You'd need to:

1. Create a new provider inline with the provider interface to fetch the credential: https://pkg.go.dev/github.com/sigstore/cosign/v2@v2.0.2/pkg/providers
2. Create a config option to tell Gitsign what to execute
3. In the sign command, initialize the provider from the config and register it.

Otherwise I can get to this eventually! 😆

Long term, once https://github.com/gitpod-io/gitpod/issues/17530 is fixed we can also look into adding a new Gitpod provider that knows how to hit the issuer endpoint directly like we do for GitHub (our plan is to move GitLab to do this once https://gitlab.com/gitlab-org/gitlab/-/issues/390711 is done)

[ChevronTango]

Thanks @wlynch. I raised https://github.com/gitpod-io/gitpod/issues/17530 and I've been in talks with @loujaybee from Gitpod who's been looking into the email JWT claims and is going to try and make some progress on that front. I'm also keen to help out with the addition of a dedicated credential helper for gitpod, though my time is also limited. I might make a start on it whilst @loujaybee is working on it from their side and hopefully we can all meet in the middle. Feel free to jump in if you know better how it should all work.

I did have an outstanding question about the support for Gitsign in GitLab and Github. Whilst signing our commits is a big step forward, if those apps don't support those signatures then we don't really have good assurance for our users. Do you know how much progress is being made on https://gitlab.com/gitlab-org/gitlab/-/issues/364428 so that our effort actually bears fruit?

[wlynch]

We've had discussions, but I can't speak to any definitive timelines on their end. (I don't work there 😅)

The right people to talk to are already on https://gitlab.com/gitlab-org/gitlab/-/issues/364428 - I'd continue to follow up there!

[ChevronTango]

thanks @wlynch, I've raised https://github.com/sigstore/cosign/issues/2997 and https://github.com/sigstore/fulcio/issues/1176 and I've also tried to follow your instructions with a quick stab at https://github.com/sigstore/cosign/pull/2998 though that will need a fair amount of work and testing before its ready. Appreciate all the input you've given