doc/user/project/repository/signed_commits/web_commits.md
{{< details >}}
{{< /details >}}
{{< history >}}
gitaly_gpg_signing. Disabled by default.rotated_signing_keys option introduced in GitLab 16.3.gitaly_gpg_signing feature flag enabled by default on GitLab Self-Managed and GitLab Dedicated in GitLab 17.0.{{< /history >}}
[!flag] The availability of this feature is controlled by a feature flag. For more information, see the history. This feature is available for testing, but not ready for production use.
When you create a commit using the GitLab user interface, the commit is not pushed directly by you. Instead, the commit is created on your behalf.
To sign these commits, GitLab uses a global key configured for the instance. Because GitLab doesn't have access to your private key, the created commit can't be signed by using the key associated with your account.
For example, if User A applies suggestions authored by User B, the commit contains the following:
Author: User A <[email protected]>
Committer: GitLab <[email protected]>
Co-authored-by: User B <[email protected]>
Before you can use commit signing for GitLab UI commits, you must configure it.
{{< details >}}
Offering: GitLab.com
{{< /details >}}
{{< history >}}
configure_web_based_commit_signing. Disabled by default.configure_web_based_commit_signing removed.{{< /history >}}
You can turn on web-based commit signing for all projects in a group, or for an individual project.
When web-based commit signing is turned on, all commits made through the GitLab UI (Web Editor, Web IDE, and merge requests) are automatically signed with the instance's configured signing key.
Prerequisites:
To turn on web-based commit signing for all projects in a group:
Projects in the group inherit this setting.
Prerequisites:
[!note] The project must not belong to a group that already has web-based commit signing turned on. If the group setting is on, the project checkbox is not available.
To turn on web-based commit signing for a project:
In Git, commits have both an author and a committer.
For web commits, the Committer field is configurable. To update this field, see
configure commit signing for GitLab UI commits.
GitLab provides multiple security features that rely on the Committer field to be set to the user who creates the commit.
For example:
Reject unverified users or Commit author's email).When a commit is signed by the instance, GitLab relies on the Author field for those features.
Commits created using the REST API.
are also considered as web-based commits.
Using the REST API endpoint, you can set author_name and author_email fields of the commit,
which makes it possible to create commits on behalf of other users.
When commit signing is enabled, commits created using the REST API that have different author_name
and author_email than the user who sends the API request are rejected.
Previously-signed commits in a branch become unsigned when:
This happens because the previous commits are modified, and added on top of the target branch. GitLab can't sign these commits.
To work around this problem, rebase the branch locally, and push the changes back up to GitLab.