Support rotation of the signing keys used for commit signatures
Current state
A git.signing_key
can be configured in order to sign commits created by Gitaly: Automated/web commits (merge or web IDE commits... (gitlab#19185 - closed). In order to tell Gitlab which commit has been signed by Gitaly, a new field Signer
has been introduced: Extend GetCommitSignatures to return Signer (!5961 - merged). A signature is verified using the configured git.signing_key
and if no error occurred, a Signer
that is equal to SIGNER_SYSTEM
is returned; otherwise, it's SIGNER_USER
value.
Problem to be solved
GetCommitSignatures
is a separate RPC that is lazily called when a commit without a cached signature in the database is requested. That's why a race condition appears:
- A commit with a signature is created
-
git.signing_key
is rotated/changed -
GetCommitSignatures
is requested and tries to verify the old signature using the new signing key and returns an error
Solution
Support configuring multiple signing keys.
Options:
-
git.signing_key
accepts multiple key paths separated by comma (or any other symbol) -
git.alternative_signing_key
to specify the next or the previous signing key -
git.signing_keys
acts likegit.alternative_signing_key
, but allows to specify multiple values. It may also deprecategit.signing_key
.
Edited by Igor Drozdov