Signed commits from the GitLab UI
- Tier: Free, Premium, Ultimate
- Offering: GitLab Self-Managed, GitLab Dedicated
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 <a@example.com>
Committer: GitLab <noreply@gitlab.com>
Co-authored-by: User B <b@example.com>
Prerequisites
Before you can use commit signing for GitLab UI commits, you must configure it.
Committer field of the commits
In Git, commits have both an author and a committer.
For web commits, the Committer
field is configurable.
By default it is set to GitLab <noreply@gitlab.com>
. 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:
- Push rules: (
Reject unverified users
orCommit author's email
). - Merge request approval prevention.
When a commit is signed by the instance, GitLab relies on the Author
field for those features.
Commits created using REST API
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.
Rebasing from UI
When signing commits made in the UI is enabled and you rebase a merge request from the UI, the commits aren’t signed.
In this case, new commits aren’t created. The merge request commits are modified and added on top of the target branch, so GitLab cannot sign them.
To have rebased commits signed, a workaround is to rebase locally and push the changes to the merge request branch.
Docs
Edit this page to fix an error or add an improvement in a merge request.
Create an issue to suggest an improvement to this page.
Product
Create an issue if there's something you don't like about this feature.
Propose functionality by submitting a feature request.
Feature availability and product trials
View pricing to see all GitLab tiers and features, or to upgrade.
Try GitLab for free with access to all features for 30 days.
Get help
If you didn't find what you were looking for, search the docs.
If you want help with something specific and could use community support, post on the GitLab forum.
For problems setting up or using this feature (depending on your GitLab subscription).
Request support