Feature: Improve support for ssh key rotation for signing #10057

New Issue

GiteaMirror · 2025-11-02T08:57:06-06:00

GiteaMirror commented

2025-11-02 08:57:06 -06:00

Originally created by @mattrpav on GitHub (Jan 4, 2023).

Feature Description

Currently, when a SSH key is removed from a user, the commits signed by that key are no longer verified in the UI. Also, there is no way to mark a key as 'revoked'-- essentially making key rotation an undefined process in Gitea.

There should be support for marking a key as 'revoked' or 'inactive' to support key rotation. This would allow for previous signed commits to remain, but new commits with that key could get the 'R' flag when signatures are verified.

Add a flag to mark an ssh key as 'revoked'
Based on 'revoke timestamp' update UI for valid signature status
Possibly support denying new commits signed by a revoked key
Support ssh keys sourced from LDAP (ie this would possibly need to be a db-only flag or have to be cached to a file in /data)

Scenarios

Active key signed commit shows as 'green'
Revoked key signed commit after revoke timestamp shows as 'red'
Revoked key signed commit before timestamp shows as 'green' and a 'revoked' indicator, possibly a 'disabled' icon next to the key id in the signature detail panel.

Motivation

In order for Gitea to be a candidate in organizations that require SOC or ISO security certifications (many .us & .eu companies) for software development lifecycle tooling, Gitea needs a clear and well-defined process for commit signing key rotation.

Technical references

Reference on supporting key revoked lists for ssh (aka KRL):
https://sleeplessbeastie.eu/2020/02/17/how-to-revoke-specific-key-used-to-login-with-openssh/

Git config for using allowed_signers and revoked_signers settings:

gpg.ssh.revocationfile=~/.ssh/revoked_signers
gpg.ssh.allowedsignersfile=~/.ssh/allowed_signers

Originally created by @mattrpav on GitHub (Jan 4, 2023). ### Feature Description Currently, when a SSH key is removed from a user, the commits signed by that key are no longer verified in the UI. Also, there is no way to mark a key as 'revoked'-- essentially making key rotation an undefined process in Gitea. There should be support for marking a key as 'revoked' or 'inactive' to support key rotation. This would allow for previous signed commits to remain, but new commits with that key could get the 'R' flag when signatures are verified. - [ ] Add a flag to mark an ssh key as 'revoked' - [ ] Based on 'revoke timestamp' update UI for valid signature status - [ ] Possibly support denying new commits signed by a revoked key - [ ] Support ssh keys sourced from LDAP (ie this would possibly need to be a db-only flag or have to be cached to a file in /data) ### Scenarios 1. Active key signed commit shows as 'green' 2. Revoked key signed commit _after_ revoke timestamp shows as 'red' 3. Revoked key signed commit _before_ timestamp shows as 'green' and a 'revoked' indicator, possibly a 'disabled' icon next to the key id in the signature detail panel. ### Motivation In order for Gitea to be a candidate in organizations that require SOC or ISO security certifications (many .us & .eu companies) for software development lifecycle tooling, Gitea needs a clear and well-defined process for commit signing key rotation. ### Technical references Reference on supporting key revoked lists for ssh (aka KRL): https://sleeplessbeastie.eu/2020/02/17/how-to-revoke-specific-key-used-to-login-with-openssh/ Git config for using allowed_signers and revoked_signers settings: ``` gpg.ssh.revocationfile=~/.ssh/revoked_signers gpg.ssh.allowedsignersfile=~/.ssh/allowed_signers ```

GiteaMirror added the type/proposal type/feature labels 2025-11-02 08:57:06 -06:00

GiteaMirror commented

2025-11-02 08:57:07 -06:00

@tionis commented on GitHub (Sep 23, 2023):

Exposing each user's allowed_signers file in general would be nice.
Even nicer if each user could also add their own certificate authority for this. (Enables a quite secure and simple ssh key setup without revoking so many keys if e.g. hardware tokens are used)

@tionis commented on GitHub (Sep 23, 2023): Exposing each user's `allowed_signers` file in general would be nice. Even nicer if each user could also add their own certificate authority for this. (Enables a quite secure and simple ssh key setup without revoking so many keys if e.g. hardware tokens are used)

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#10057