Skip to main content

About commit signature verification

Using GPG, SSH, or S/MIME, you can sign tags and commits locally. These tags or commits are marked as verified on GitHub Enterprise Cloud so other people can be confident that the changes come from a trusted source.

About commit signature verification

You can sign commits and tags locally, to give other people confidence about the origin of a change you have made. If a commit or tag has a GPG, SSH, or S/MIME signature that is cryptographically verifiable, GitHub Enterprise Cloud marks the commit or tag "Verified" or "Partially verified."

Verified commit

For most individual users, GPG or SSH will be the best choice for signing commits. S/MIME signatures are usually required in the context of a larger organization. SSH signatures are the simplest to generate. You can even upload your existing authentication key to GitHub Enterprise Cloud to also use as a signing key. Generating a GPG signing key is more involved than generating an SSH key, but GPG has features that SSH does not. A GPG key can expire or be revoked when no longer used. GitHub Enterprise Cloud shows commits that were signed with such a key as "Verified" unless the key was marked as compromised. SSH keys don't have this capability.

Commits and tags have the following verification statuses, depending on whether you have enabled vigilant mode. By default vigilant mode is not enabled. For information on how to enable vigilant mode, see "Displaying verification statuses for all of your commits."

注意: 警惕模式目前处于测试阶段,可能会发生变化。

Signing commits differs from signing off on a commit. For more information about signing off on commits, see "Managing the commit signoff policy for your repository."

Default statuses

StatusDescription
VerifiedThe commit is signed and the signature was successfully verified.
UnverifiedThe commit is signed but the signature could not be verified.
No verification statusThe commit is not signed.

Signature verification for rebase and merge

在拉取请求上使用“变基与合并”时,请务必注意,头分支中的提交将添加到基分支,无需提交签名验证。 使用此选项时,GitHub 会使用原始提交的数据和内容创建修改的提交。 这意味着 GitHub 未真正创建此提交,因此无法将其签名为通用系统用户。 GitHub 无权访问提交者的专用签名密钥,因此无法代表用户对提交进行签名。

解决方法是在本地进行变基和合并,然后将更改推送到拉取请求的基分支。

For more information, see "Rebasing and merging your commits."

Statuses with vigilant mode enabled

状态说明
已验证提交已签名,签名已成功验证,并且提交者是启用警戒模式的唯一作者。
部分验证提交已签名,签名已成功验证,但提交的作者:a) 不是提交者,并且 b) 已启用警戒模式。 在这种情况下,提交签名并不保证作者的同意,因此提交只得到部分验证。
未验证以下任一项是正确的:
- 提交已签名,但签名无法验证。
- 提交未签名,并且提交者已启用警戒模式。
- 提交未签名,并且创建者已启用警戒模式。

Repository administrators can enforce required commit signing on a branch to block all commits that are not signed and verified. For more information, see "About protected branches."

您可以在 GitHub Enterprise Cloud 上检查已签名提交或标记的验证状态,并查看提交签名未验证的原因。 有关详细信息,请参阅“检查提交和标记签名验证状态”。

GitHub will automatically use GPG to sign commits you make using the web interface. Commits signed by GitHub will have a verified status. You can verify the signature locally using the public key available at https://github.com/web-flow.gpg. The full fingerprint of the key is 5DE3 E050 9C47 EA3C F04A 42D3 4AEE 18F8 3AFD EB23.

You can optionally choose to have GitHub GPG sign commits you make in GitHub Codespaces. For more information about enabling GPG verification for your codespaces, see "Managing GPG verification for GitHub Codespaces."

GPG commit signature verification

You can use GPG to sign commits with a GPG key that you generate yourself.

GitHub Enterprise Cloud uses OpenPGP libraries to confirm that your locally signed commits and tags are cryptographically verifiable against a public key you have added to your account on GitHub.com.

To sign commits using GPG and have those commits verified on GitHub Enterprise Cloud, follow these steps:

  1. Check for existing GPG keys
  2. Generate a new GPG key
  3. Add a GPG key to your GitHub account
  4. Tell Git about your signing key
  5. Sign commits
  6. Sign tags

SSH commit signature verification

You can use SSH to sign commits with an SSH public key that you generate yourself. If you already use an SSH key to authenticate with GitHub Enterprise Cloud, you can also upload that same key again for use as a signing key. There's no limit on the number of signing keys you can add to your account.

GitHub Enterprise Cloud uses ssh_data, an open source Ruby library, to confirm that your locally signed commits and tags are cryptographically verifiable against a public key you have added to your account on GitHub.com.

Note: SSH signature verification is available in Git 2.34 or later. To update your version of Git, see the Git website.

To sign commits using SSH and have those commits verified on GitHub Enterprise Cloud, follow these steps:

  1. Check for existing SSH keys
  2. Generate a new SSH key
  3. Add a SSH signing key to your GitHub account
  4. Tell Git about your signing key
  5. Sign commits
  6. Sign tags

S/MIME commit signature verification

You can use S/MIME to sign commits with an X.509 key issued by your organization.

GitHub Enterprise Cloud uses the Debian ca-certificates package, the same trust store used by Mozilla browsers, to confirm that your locally signed commits and tags are cryptographically verifiable against a public key in a trusted root certificate.

注意:S/MIME 签名验证可用于 Git 2.19 或更高版本。 若要更新 Git 版本,请参阅 Git 网站。

To sign commits using S/MIME and have those commits verified on GitHub Enterprise Cloud, follow these steps:

  1. Tell Git about your signing key
  2. Sign commits
  3. Sign tags

You don't need to upload your public key to GitHub Enterprise Cloud.

Signature verification for bots

Organizations and GitHub Apps that require commit signing can use bots to sign commits. If a commit or tag has a bot signature that is cryptographically verifiable, GitHub Enterprise Cloud marks the commit or tag as verified.

Signature verification for bots will only work if the request is verified and authenticated as the GitHub App or bot and contains no custom author information, custom committer information, and no custom signature information, such as Commits API.

Further reading