workflows: Add OIDC token generation workflow

[tetsuo-cpp]

My plan is to get this in first. And then once we have tokens being generated continuously, I'll be able to develop/test against these tokens.

[woodruffw]

LGTM!

[haydentherapper]

Doesn’t this leak the token publicly? Actions output is publicly viewable. You could first encrypt it with a repository secret?

[haydentherapper]

Cc @woodruffw @tetsuo-cpp

[woodruffw]

Doesn’t this leak the token publicly? Actions output is publicly viewable. You could first encrypt it with a repository secret?

Indeed it does, and that's intended -- all third-party PRs that would otherwise be unable to access an OIDC credential are expected to use this broadcasted token.

We could encrypt it with a secret, but that secret would have to be shared with every conformance suite user -- maybe that's an acceptable tradeoff?

[haydentherapper]

I expect conformance tests to run in Sigstore org managed repos, so we could create an org secret?

Having the token leaked publicly feels problematic though. It allows for repository impersonation, which maybe is fine because nothing sensitive happens in this repo, but if you hooked up workload identity, now you’d have access to a cloud project.

[woodruffw]

I expect conformance tests to run in Sigstore org managed repos, so we could create an org secret?

That works for me, assuming we expect all future Sigstore clients to be hosted under the Sigstore org (which strikes me as a reasonable assumption, although sigstore-python started out under the Trail of Bits org before we moved it).

Having the token leaked publicly feels problematic though. It allows for repository impersonation, which maybe is fine because nothing sensitive happens in this repo, but if you hooked up workload identity, now you’d have access to a cloud project.

Yeah, this was the reasoning: the token in question is scoped to a specific workflow (which we could name even more distinctly, perhaps something like this-token-is-fundamentally-insecure-and-only-useful-for-testing.yml), and is for a repository that should never have any sensitive operations delegated to it.

[di]

I expect conformance tests to run in Sigstore org managed repos, so we could create an org secret?

I think we should do this.

Yeah, this was the reasoning: the token in question is scoped to a specific workflow (which we could name even more distinctly, perhaps something like this-token-is-fundamentally-insecure-and-only-useful-for-testing.yml), and is for a repository that should never have any sensitive operations delegated to it.

And also this.

[tetsuo-cpp]

@haydentherapper @di @woodruffw

I expect conformance tests to run in Sigstore org managed repos, so we could create an org secret?

I looked into this a bit today. However, I don't think this is going to work.

For each client, the workflow that runs the conformance tests will need to decrypt the OIDC token. This will require access to the org secret and therefore, won't be accessible from third-party PRs unless we use pull_request_target (which is what we're trying to avoid here).

Regardless of what we do, I think we'll need to accept that this identity will be publicly accessible. Even if we have some scheme to encrypt it, a third-party PR to a client could modify the client code to share the OIDC token elsewhere which isn't materially different from just having it available as a job artifact.

I realise it's not ideal, but I think @woodruffw's PR to rename the workflow name should be sufficient as the filename will be embedded in the identity and will serve as a warning against any misuse.

If we agree to this, I can switch the OIDC workflow back on and modify the action to use these tokens.

[woodruffw]

Regardless of what we do, I think we'll need to accept that this identity will be publicly accessible. Even if we have some scheme to encrypt it, a third-party PR to a client could modify the client code to share the OIDC token elsewhere which isn't materially different from just having it available as a job artifact.

Yeah, agreed -- I keep forgetting about this fundamental constraint. Any additional encryption we end up doing here will end up being obfuscation, rather than actually providing confidentiality.

I want @di and @haydentherapper to see this before we flip it back on, but let's go ahead and open the PR with the action modifications in the mean time.

[haydentherapper]

My primary concern is a weak verification policy somewhere that says "if org = sigstore, trust token". Obviously this is user-error, but having these tokens be public makes this too easy.

Sorry to rehash what's been discussed already, but why couldn't we use pull_request_target with an explicit checkout and include a label like "safe to run" once someone's reviewed the code?

[woodruffw]

Sorry to rehash what's been discussed already, but why couldn't we use pull_request_target with an explicit checkout and include a label like "safe to run" once someone's reviewed the code?

No problem at all -- this has been a long discussion, and a lot of state has been shed throughout the course of it 🙂

The primary issue we ran into with the label-based workflow (which is what we currently support) was clunkiness: re-running the conformance suite requires the maintainers to re-label the PR each time it changes, unless we'd be willing to trust the PR author after their first commit (which would then enable "trojan horse" PRs, where the first commit starts reasonably and subsequent PRs are malicious).

I talked a bit with @bobcallaway over DM, and I think his solution is the most workable here: sigstore/sigstore-conformance should continue to live under the Sigstore org, but we can create a separate Sigstore-controlled org for the OIDC "beacon" to live under. From there we could publicly disclose tokens that are scoped as sigstore-conformance/extremely-dangerous-public-oidc-beacon.

[haydentherapper]

Thanks for the explanation! +1 to the approach of using a different org for the OIDC token.