Signed commits in the GitLab web interface (IDE)
This topic explains how commits created through the GitLab web interface on the SHIP-HATS platform are digitally signed and how the committer details appear in your repository history.
If you are committing from your local IDE or CLI, ensure you have Set up keys. This is because, when you commit via Web IDE, your commits are signed automatically by SHIP‑HATS, but local commits require your own signing key.
Enabling security for web-based commits
SHIP-HATS enables the signed commits feature for its users from 15 January 2026.
To improve security and ensure integrity, all changes committed using the GitLab web platform (including the Web IDE, Web Editor, and Merge Request edits) are now automatically signed by GitLab and marked as verified in GitLab, indicating that the system successfully validated the commit signature.
This process establishes a clear and verifiable source for all web-based code changes.
How committer details appear
The committer information recorded in the commit history will differ between local and web-based commits. This distinction ensures the system’s signature is recorded for verification purposes.
| Commit source | Committer name | Committer email | Signature status |
|---|---|---|---|
| Local IDE / Git client | The individual developer’s name | The individual developer’s email | One of the following badges: - Verified: If the commit is signed and GitLab can validate the signature against a public key (GPG/SSH key) linked to the committer’s account. - Unverified: Commit is signed but GitLab cannot validate the signature. - No badge: Commit is not signed. |
| GitLab web interface (Web IDE, Web Editor, MR edits) | GitLab |
noreply@sgts.gitlab-dedicated.com |
Verified |
When you commit via the web interface, GitLab is recorded as the Committer for verification purposes. However, you will always be listed as the Author of the changes, ensuring your contribution is fully recognised.
Additional resources
GitLab documentations
