Add a "only allow commits with defined identity" setting

[Classic298]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Supply chain security

Discussion Details

Why

Anyone triaging security reports for large repos, doing PRs, maintaining software used by many enterprises, even governments, will eventually be targeted by phishing and social engineering attacks to attempt to pursue supply chain attacks.

People who triage vulnerability reports for software running in government, healthcare, and regulated enterprise environments have concrete reasons to keep a legal name off a public commit history, and they push from more machines, more often, under more time pressure than most.

This would be considerably harder if GitHub were able to offer the following opt-in setting in the account settings:

The Ask

An opt in account setting that says basically:

Only allow commits with my defined identity
Reject any push from my account containing commits whose author or committer is not my defined identity.

The defined identity is my GitHub noreply@ address and my chosen GitHub name. Rejection should name the offending commit and print the expected identity, the way GH007 already does.

Why the existing setting is not enough

"Block command line pushes that expose my email" only fires on addresses already verified and marked private on my account. Every other value sails through.

A device configured with a work address, a client address, a personal address I never registered, or my real legal name pushes cleanly. GitHub accepts the commit, cannot map the address to any account, and publishes it unattributed with whatever name and address were in the config.

This results in e.g. a work address or a personal address configured in the local git client to leak through to GitHub, attributing said email permanently to the account.

The current setting reads like identity protection, which it isn't. It covers one narrow case which is committing using an email I specifically added to my account and verified. I enabled it and assumed I was covered.

Why this matters

Multiple git identities on one machine is the normal state for anyone working across employers, clients, and personal projects. Global config says one thing, a repo local config says another, a fresh device says nothing at all and picks up whatever is lying around. Getting it wrong is a one character mistake in a file nobody looks at.

The mistake is permanent. A public commit is cloned, forked, mirrored, indexed, and archived within minutes. Deleting the branch does not recall it. There is no operation available to me that undoes the disclosure.

For maintainers of widely deployed software this is not a tidiness issue. Real name and email address are targeting data. People who triage vulnerability reports for software running in government, healthcare, and regulated enterprise environments have concrete reasons to keep a legal name off a public commit history, and they push from more machines, more often, under more time pressure than most.

Git will not solve this. The author field is free text, applied silently, with no confirmation step and no warning. The only place a guard rail can sit is the push.

Scope

Opt in, no effect on anyone who leaves it off. Applies to pushes from my account across every repository, including forks and repositories I do not own, since those are exactly the ones where a leak is unrecoverable.

An organisation level version, letting an org require this of its members, would extend the same protection to maintainer teams.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[Classic298]

Follow up with a concrete spec:

Config

• Of course, primarily, the user needs to enable this opt in feature. Off by default.
• Allowed identities. Upon enabling the feature, the user has to provide at least one allowed identity. This is to be prefilled with the account's noreply address and profile name. Therefore, that "one required identity" is provided by default. A user can add up to 10 additional entries, for bot identities used by workflows pushing with their token.
• Allowed Identities cannot include verified emails marked as private.
• Protected values. Also it is to be prefilled with every other verified email on the user's account.
• If you want to DISABLE the feature, disabling offers an optional auto expiry (automatic re-enablement) (1h / 8h / 24h / manual, default 24h). Useful when you temporarily need to import foreign repositories with foreign data.

Rules

1. Evaluate only objects in the push quarantine set, the same delta secret scanning push protection already inspects.
2. The committer must be in the "Allowed Identities" set.
3. The author ALSO must be in the "Allowed Identities" set.
4. Trailers are unvalidated, but not ignored. Co-authored-by and Signed-off-by are rejected only on match against existing protected values (private verified emails). Sign off matters here as much as co-authorship: git commit -s writes user.name and user.email into the message body verbatim, so on any DCO project a misconfigured client leaks the identity on every single commit, in a field the author/committer allowlist never inspects.
5. Tag objects included, since the tagger field leaks identically. Worth being explicit about, because the equivalent GitLab push rules apply to commits only and not tags, which is an open gap over there (gitlab#498336).
6. refs/notes/* included, since note objects carry committer identity.
7. Server side commits (merge, squash, rebase, web editor) are never evaluated. GitHub generates those identity fields itself.
8. Pushes over a deploy key are out of scope. They carry no user attribution for an account level policy to attach to.

Optional sub setting: "allow foreign authors when I am the committer." Off by default, so rule 3 stands unless you turn it on. This covers the maintainer who pushes a contributor's branch after review, where the foreign commits are legitimate and may not already be in shared object storage if they came from outside the fork network. GitLab reached the same compromise for its name check: compare committer email against author email first, and skip the author check when they differ, specifically so cherry picks and rebases are not blocked.

Cost

A set membership test per object against a set bounded at 10, plus one policy lookup per push, cacheable per account. No index over other accounts, no attribution lookup. An unrecognised value does not need to be identified, only observed to be absent.

If no trailers are present, you can skip the matching against protected values altogether.

If this new feature is toggled on and the allowlist check passes (committer and author both in the set of Allowed Identities) then the existing blocklist check can be skipped, since Allowed Identities cannot contain a private verified email by construction. The allowlist is strictly stricter than the blocklist, so it subsumes it.

The one genuinely new cost is the policy lookup on pushes from users who currently have the private email setting off and therefore run no identity check at all today. That is a cached read of a bounded list, gated behind an opt in that most accounts will never enable.

Rejection

Reject the whole push, not the ref update alone. Follow the GH007 presentation: name the first offending commit, both fields, the expected value, the fix command.

Use a distinct error code, not GH007 itself, so client tooling and wrappers can tell a policy rejection apart from a private email rejection and surface the right remediation.

Whole push rejection is the load bearing requirement, not a UX preference. Ref update rejection leaves the objects on the server, which is the exact disclosure this is meant to prevent.

Known gap: the Contents API

PUT /repos/{owner}/{repo}/contents/{path} accepts a caller supplied author.name and author.email, and plenty of tooling populates those from local git config. That path is user supplied identity rather than GitHub generated, so it is not covered by the rule 7 exclusion in spirit. Closing it is a phase two item and does not block the push side, which is where the overwhelming majority of accidental leaks happen.

What would require toggling off

Imports and mirror pushes. Local rebase, squash or git am of commits from outside the network, if the foreign author sub setting is off. These are deliberate, planned and reversible in seconds. The leak they guard against is silent and permanent.

Merging a fork's branch needs no toggle: shared object storage means only the merge commit is new, and you authored it.

Why this is not covered by rulesets

Two reasons, and the second is the important one.

They belong to the receiving repository and are Enterprise gated. They cannot protect a push into a repository you do not own, which is exactly where the disclosure is unrecoverable.

They block ref updates, not pushes. Per the docs: "If a contributor pushes work that includes a commit that doesn't meet the requirements, the push is not rejected, but the branch or tag they are targeting is not updated." For a consistency rule that behaviour is correct. For a disclosure rule it fails open, because the objects reach the server regardless.

Prior art

GitLab ships close equivalents as push rules: Reject unverified users requires the committer email to match one of the user's verified addresses or their private commit email, and Reject inconsistent user name requires the author name to match the account name. So the check is known implementable at pre receive, and the demand is real enough that a competitor built it.

Both are project and group scoped, so they inherit the same receiver side limitation as rulesets. Account scoped enforcement that follows the user into repositories they do not control is the part nobody offers yet.

[Classic298]

Philosophy

We all have seen many supply chain attacks in the past, but also recently.
Governments around the world are looking into using more Open Source Software or Software with Licenses that allow free use. The more governments or large enterprises use these pieces of software, the larger the risk to MAINTAINERS, COLLABORATORS and SECURITY TRIAGEURS to fall victim to extremely sophisticated, targeted social engineering campagins.

This toggle, if introduced, would not mitigate that but would make the attack surface slimmer, make it a bit harder to gather data about a person and protect their identity from these threat actors.

Times change, GitHub has gained an insane amount of popularity recently as the cost of entering the open source world has been lowered drastically thanks to AI. More people, enterprises and governments using software found on GitHub is great but also steadily increases the risk on those maintaining it. GitHub should take action to introduce more controls like this optional feature to protect those who uphold what makes this platform valuable in the first place.

[mubashir1osmani]

+1 i agree, we've had this problem of receiving phishing emails by our maintainer's name every so often

id really like our org to have this functionality