doc/user/project/repository/signed_commits/_index.md
{{< details >}}
{{< /details >}}
When you add a digital signature to your commit, you provide extra assurance that a commit originated from you, rather than an impersonator. A digital signature is a cryptographic output used to verify authenticity.
It's important to understand the difference between signed and verified commits:
If GitLab can verify the committer's identity with a public key, the commit is marked Verified in the GitLab UI.
[!note] The committer and author fields are distinct in Git. The author writes the commit, and the committer applies it. Commit signing verifies only the committer's identity.
GitLab verifies signatures on commits and tags. The following signing methods are supported:
To review commits for a merge request, or for an entire project, and verify they are signed:
In the top bar, select Search or go to and find your project.
To review commits:
Identify the commit you want to review. Depending on the verification status of the signature, signed commits display either a Verified or Unverified badge.
Unsigned commits do not display a badge.
To display the signature details for a commit, select Verified or Unverified to see the fingerprint or key ID:
You can also use the commits API to check a commit's signature.
GitLab uses SSH to sign commits created through the web UI. To verify these commits locally, obtain the GitLab public key for signing web commits using the web commits API.
{{< history >}}
check_for_mailmapped_commit_emails. Disabled by default.{{< /history >}}
[!flag] The availability of this feature is controlled by a feature flag. For more information, see the history. This flag enables the infrastructure for
mailmapdetection. Fullmailmapsupport requires additional configuration and is not yet enabled by default.
When a verified signed commit's committer email is no longer verified to the signing user, GitLab displays an orange verified badge with a warning sign ({{< icon name="warning" >}} Verified).
This can occur when:
.mailmap file remaps the committer
email to an address not verified by the signing user.To restore the green Verified badge, add the committer email address to your GitLab profile and verify it.
{{< details >}}
{{< /details >}}
You can require signed commits across your projects using push rules. The Reject unsigned commits push rule prevents any unsigned commits from being pushed to a repository, helping organizations maintain code integrity and meet compliance requirements.
For more information about how this rule works and its limitations, see require signed commits.
The verification process for commits signed with GPG keys or X.509 certificates can fail for multiple reasons:
| Value | Description | Possible fixes |
|---|---|---|
UNVERIFIED | The commit signature is not valid. | Sign the commit with a valid signature. |
SAME_USER_DIFFERENT_EMAIL | The GPG key used to sign the commit does not contain the committer email, but does contain a different valid email for the committer. | Amend the commit to use an email address that matches the GPG key, or update the GPG key to include the email address. |
OTHER_USER | The signature and GPG key are valid, but the key belongs to a different user than the committer. | Amend the commit to use the correct email address, or amend the commit to use a GPG key associated with your user. |
UNVERIFIED_KEY | The key associated with the GPG signature has no verified email address associated with the committer. | Add and verify the email to your GitLab profile, update the GPG key to include the email address, or amend the commit to use a different committer email address. |
UNKNOWN_KEY | The GPG key associated with the GPG signature for this commit is unknown to GitLab. | Add the GPG key to your GitLab profile. |
MULTIPLE_SIGNATURES | Multiple GPG or X.509 signatures have been found for the commit. | Amend the commit to use only one GPG or X.509 signature. |