-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Verify: require cert to match committer? #104
Comments
Yeah, I think the default of "check that someone signed but not who" is pretty dangerous in general and I strongly support being able configure a "verification policy" (with some sensible default; I think the proposed policy is a good one). Options include:
|
I like this in general. Another check we could add is that the timestamp in the commit is during the validity window of the cert, to prevent signing "backdated" commits. |
Some more thinking about this - using committer emails to verify against for human users should be relatively easy, but we still need to figure out:
I'm thinking we'll probably need to make a new |
Oof, this is really tricky and important to get right. There's no canonical IdP for a given email (see also sigstore/cosign#1947). <warning: I'm going to repeat myself a bunch below 😄 > That said: I think we can push this problem to wherever we're solving the problem of "whose commits do I trust, in general?" If you e.g. configure a policy that says "for repo X, I trust Not sure if this is technically feasible with the hooks we have into Git, but I think putting the the issuer in the commit would be no worse security-wise than where we are today. |
Did something thinking + experimentation around this - here's a rough proposal: For User EmailsThis is the simplest case, since we should generally have a valid email associated to the commit that should match the cert. For
This allows us to keep compatibility with existing git workflows while still giving users control to restrict down usage. It's probably unreasonable to require users to pre-configure the list of identity providers per repo, since this may vary per repo or even per user. Robot emailsAutomated workflows (Kubernetes, GitHub Actions, etc.) present more of a challenge, because we don't have a clear email to use for each service account user. For these cases, we propose allowing tools to set specialized Git committer user names that gitsign will know how to interpret. These should match the identity formats we are aiming to support for other tools (e.g. cosign). Gitsign will need to parse the identifiers to extract them and compare against the claims included in the cert. We can reuse the e.g. for GitHub Actions, the way to attribute commits to actions is to use the special With this, we could have gitsign clients populate a special username + email - i.e. NOTE: technically user names in emails should be max 64 characters, but since we're using this primarily for signature validation and service account identities will likely have noreply emails associated with them anyway, we are ignoring this restriction w.r.t. git and gitsign verification. For email based git workflows, the user name can be truncated if necessary - we're considering the git repo itself to be the source of truth for validation. AlternativesWe've observed that GitHub is actually quite a bit permissive in what emails it lets you associate (
We could use this to include identity information in the email itself, but since we don't control the domain this feels much riskier to rely on for stability without GitHub's blessing. |
In this case, I would strongly recommend hard-coding a default I support teaching users (including gitsign itself, as well as gitsign users) that "Fulcio issues a cert" means only "Fulcio saw a very specific OIDC token," not "the recipient of the cert controls this email/identity." To that end, I am in favor of adding a "blank check" OIDC provider that will give you free certs to any username/email you'd like. My opinion here is very extreme, but the broader point isn't (see sigstore/fulcio#639).
Users very quickly learn to ignore security warnings 1, 2, 3, 4. (I'm okay with a warning for a deprecation period.)
My immediate reservation is that "trusted IDP" makes more sense on a per-identity basis than a per-repo or even per-domain basis. If I have a I think it does cover the 80% case, though. w/r/t default policy: the whole situation feels a little no-win. That might indicate that the long-run state would be: (1) for ideal security, you configure some policy (in the repo/forge, or, if necessary, in your global/user/repo gitconfig) about trusted identities, and (2) otherwise, you're not using the power of gitsign, and the verification it gives you is a little weak.
That issue doesn't seem to be the exact relevant one: it's just saying that subjects in X.509 certs have "types," and any given instance of Fulcio (1) should:
So for parity, you'd just need to know know type of the subject. This is embedded in the X.509 cert: $ step certificate inspect /tmp/cert.pem | grep -A1 "X509v3 Subject Alternative Name"
X509v3 Subject Alternative Name: critical
email:zjn@chainguard.dev But it really shouldn't matter—Fulcio will only ever issue certs with appropriate types. I think what you're looking for is a canonical string representation of an (identity provider, username/email) tuple in the Sigstore world, which is a great idea and something I've wanted before (I don't know if it's tracked anywhere). You may want the ability to query arbitrary claims in the cert as well. If that becomes urgent, I can help spec something out.
Yes, once we have such a way to represent identities as strings, I think this is a great way to encode them.
I agree that username is possibly more natural. But the "is this stable in GitHub" question is eminently resolvable, since we do have interested GitHub folks in the Sigstore community. |
Inspired by this Issue, I created a Github Action that tries to catch all possible scenarios of signed (and unsigned) commits In the README's scenarios section there are some cases that this Github Action would fail to verify a signed commit, given some security assumption. The Github Action |
This could be a disruptive change to users, so looking for feedback before we commit to this - should we require by default that the cert contained in the git commit match the email of the git committer?
Right now we just check for a valid signature, and users would need to add additional checks to verify the identity matches.
This would be in line with Sigstore clients should require a provided identity by @haydentherapper and @znewman01, since we don't have an easy way to pass additional params via
git verify-commit
orgit log
. This also means we don't have a good way to specify the OIDC provider or Sigstore instance, so we may need additional out of band config (i.e. envvar / #99) for this to be complete.#65 may be a hard requirement here, since otherwise we won't be able to generate privacy preserving certs. We could also provide an option to disable this behavior (though prefer not to do this if possible).
Thoughts? cc @imjasonh @nsmith5
The text was updated successfully, but these errors were encountered: