Commit signing for GitLab UI commits on GitLab.com
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Background
In 17.0, we introduced commit signing for GitLab UI commits for Self-Managed and Gitlab Dedicated. Previously, web commits and automated commits made by GitLab could not be signed. Now you can configure your self-managed instance with a signing key, a committer name, and email address to sign web and automated commits.
Documentation (Self-Managed and Gitlab Dedicated):
We are now looking to introduce this feature on GitLab.com. Once this is introduced, we will sign web commits and automated commits made by GitLab for all GitLab.com projects.
Proposal
Once the feature is enabled on GitLab.com, we will sign automated and web commits for all projects. We will configure GitLab.com with:
- A global signing key
- A committer name:
GitLab - A committer email:
no-reply@gitlab.com
Note: Because GitLab doesn’t have access to a user's private key, the created commit can’t be signed by using the key associated with the user account.
Potential breaking changes
Changes to the committer name and email
The change to the committer name and email is not expected to break any GitLab functionality. However it could potentially impact a team's internal tooling if these fields are used. We want to ensure we communicate ahead of time through a blog post to let teams know there is a risk of impact to internal tooling if they are using the committer name and/or email.
Once the feature is enabled on GitLab.com, the committer name and email will change and will impact the content of commits, such as in the case of applying suggestions:
For example, if User A applies suggestions authored by User B, the commit will contain the following:
Author: User A <a@example.com>Committer: GitLab <noreply@gitlab.com>Co-authored-by: User B <b@example.com>
Commits created using the REST API
This change will also have an impact on commits created using the 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 will be rejected.
This change:
- could require an action from the customer to ensure continuity of function.
- could cause a disruption to a customer’s workflows or tasks.
As such, we are treating it according to our breaking change policy.
Limitations
There are certain limitations to the commits that GitLab can sign as explained in our documentation for Signed commits from the GitLab UI. One limitation is 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.