Signed Commit Setup for GitLab
GitLab Signed Commits
Introduction
This outlines the procedure of setting up signed commits for a GitLab Data Source Credential. This procedure walks through the process from configuring the GPG key in the container, adding the key to GitLab, and also enabling the use of the key in Command Center.
Use Case
There are instances within organizations where all commits that are made into a repository must signed in order to allow them to be committed to the repository. The below instructions will walk through the configuration required in Command Center to permit signed commits to occur specifically within a GitLab repository.
Procedure Overview
- Generate a new GPG Key in the Command Center Docker Container
- List the generated public keys to confirm they were correctly created.
- Export the public key so that it can be added to the GitLab user as a new GPG key for signing purposes.
- Add the public key to the repository owner(s) that will be leveraging the signed commits in GitLab
- Configure a Data Source Credential in Command Center to use signed commits.
- Configure the project(s) in Command Center that will use the Data Source credential,
- Validation of the signed commit ability for the project(s).
Procedure
Generate a new GPG Key in the Command Center Docker Container
A new GPG public and private key will need to be generated within the container. To achieve this, log into the VM that contains the Command Center running container and log into the container as the user that the container is running as.
sudo docker exec -it `sudo docker ps | grep lingoport/command-center | awk '{print $1}' ` bash '''
This will place you in the home directory of the tomcatuser. From there the new GPG keys can be created. To complete this task the following will be required.
- The email address that the key will be assigned to. This is important as the email address will be verified when the key has been added to Gitlab. Also, this email address will be placed in Command Center as the commit email address performing the signing.
- The user name associated with the email address. This will also be placed in Command Center as the commit author.
Run the below command.
Note that here the default was selected RSA and RSA key types and also no expiration for the key. Security policies vary so that may not be the correct choice for your organization. Be sure to check with your InfoSec team when unsure.
gpg --full-generate-key
gpg (GnuPG) 2.2.27; Copyright (C) 2021 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
(14) Existing key from card
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (3072) 3072
Requested keysize is 3072 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 0
Key does not expire at all
Is this correct? (y/N) y
GnuPG needs to construct a user ID to identify your key.
Real name: Tim the Enchanter
Email address: tim@bewaretherabbit.org
Comment:
You selected this USER-ID:
"Tim the Enchanter <tim@bewaretherabbit.org>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
At this point a pass phrase box appears.
Be sure to simply select < OK >, you do not want a phrase to be applied to the key. Also, you will likely see the below boxes a couple of times. That is fine, simply select < OK > and <Yes, protection is not needed> each time.
lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
x Please enter the passphrase to x
x protect your new key x
x x
x Passphrase: ________________________________________ x
x x
x <OK> <Cancel> x
mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj
lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
x You have not entered a passphrase - this is in general a bad idea! x
x Please confirm that you do not want to have any protection on your key. x
x x
x <Yes, protection is not needed> <Enter new passphrase> x
mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj
Once this occurs the key is created and there will be a message similar to the below.
gpg: key ABC123DEF4567890 marked as ultimately trusted
gpg: revocation certificate stored as '/usr/local/tomcat/.gnupg/openpgp-revocs.d/1234567890ABCDEF1234567890ABCDEF12345678.rev'
public and secret key created and signed.
pub rsa3072 2026-10-15 [SC]
1234567890ABCDEF1234567890ABCDEF12345678
uid Tim the Enchanter <tim@bewaretherabbit.org>
dub rsa3072 2026-10-15 [E]
To list the public keys use this command
gpg --list-keys --keyid-format=long
pub rsa3072/ABC123DEF4567890 2026-10-15 [SC]
1234567890ABCDEF1234567890ABCDEF12345678
uid [ultimate] Tim the Enchanter <tim@bewaretherabbit.org>;
The next thing that is needed is to export the public key in a format that can be imported into GitLab.
Be sure to do this with the public key and not the private one, that is very important from a security standpoint.
Using the above example, copy the ABC123DEF4567890 (the contents after the "rsa3072/" and use it as the argument to the export switch similar to what is shown below. The size of this is based upon the key size, so it will likely be larger than this example.
gpg --armor --export ABC123DEF4567890 -----BEGIN PGP PUBLIC KEY BLOCK----- mDMEatD3IxYJKwYBBAHaRw8BAQdAG5RYA9/+gU4mB9gDHQp2BxYGS5e1fTMC1fKl pMM2Ndi0K1RpbSB0aGUgRW5jaGFudGVyIDx0aW1AYmV3YXJldGhlcmFiYml0Lm9y Zz6IlgQTFgoAPhYhBENjyvdwvQM8kA8lRtWqiMQzJgAbBQJq0PcjAhsDBQkB4TOA BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJENWqiMQzJgAb8wQBAPKDP6b9G+gV u2Qveht/jTv+vRjFSWewJ+OzGqEqSZkUAP9yk49QrFMgqpNMbh9f/cWGnKs8fvBR Fi8/doXDz+msDw== =vOD1 -----END PGP PUBLIC KEY BLOCK-----
Copy this public key and put it in a safe place. It will be used in the next section.
An additional note regarding the keys.
Since this is a container that the keys are being generated in, they are ephemeral and will no longer exist after the next Command Center upgrade or even simple reinstall of the same version of Command Center. It would be a good idea to copy the entire .gnugp directory (making note of the ownership and permissions) and storing them in a safe place as they contain the private keys. Using tar and zip would be a good option for this. Do this only if your organization permits it. If it does not, these will have to be generated fresh after ever new installation or upgrade.
At this point the work in the container itself is complete. Feel free to exit the container and the VM.
Adding the Generated Public Key to GitLab
The next step is to add the public key generated to the owner of the GitLab repo(s) that are going to benefit from the signed commits.
Log into the Gitlab account as the user that will be leveraging the signed commits and select their icon in the upper right corner on the landing page. Then select Preferences.
On the left side bar. Navigate down the bar and select Access -> GPG Keys.
In the GPG Keys page. Select the Add new key button.
A new window appears where the key can be copied into.
Once the Add Key button is pressed the key will be added to GitLab.
If it is the same user as the user account it will appear as verified immediately and an email will be send to that email address indicating that the key has been successfully added.
Configuring Command Center to Use the Key
To configure Command Center go into the Settings->Credentials screen and either create a new GitLab credential. To support signed commits select the "Signed Commits" switch and then fill in the Commit author and the Commit email text boxes with the same user and email address that was used for the key.
At this point any project in CC that is leveraging this credential should automatically sign all commits that are applied in GitLab.
Validation
To validate the success of the addition, simply commit a change to your repository using Command Center. For an existing repository this can be easily done by enabling pseudo localization, save the the project, and then run the analysis. This will automatically commit to the repo an "eo" by default locale. Then check in GitLab to confirm that there is a green "Verified" entry in the commit as shown below.
At this point, your configuration is complete.