SSH key commit signing #13165

New Issue

GiteaMirror · 2025-11-02T10:33:17-06:00

GiteaMirror commented

2025-11-02 10:33:17 -06:00

Originally created by @hozza on GitHub (Jun 16, 2024).

Description

I had some trouble using SSH key singing on Gitea. I'm adding this issue to help others who may be searching for solutions and to suggest some improvements. I'll try to contribute to these issues myself when I have the time also.

Access SSH key and Signing SSH key are one-and-the-same in Gitea. In Github an SSH key for signing can be separate from the SSH key used for access. This means that if you migrate from Github where you used separate access and signing keys, it's required that your singing key must now be used for git clone/pull/push access too within Gitea and there's no way to prevent this. This is not the case with GPG singing though.
Unclear "Unverified" message on singing SSH keys. This is being worked on in #20608. Essentially, even once you've uploaded the signing SSH key, it will still say "no known key found" when it should say "found key is unverified" or something of that nature.
During a PR merge, even when singing ssh keys are working, a PR merge from the web on Gitea will still say "There is no key available to sign this commit.". I don't remember how Github handles this, but gitea could explain why it cannot sign (it doesn't have the priv key?).
UX & Docs. The docs are pretty sparse on SSH keys, and SSH key singing as they only referencing GPG singing. On the key settings (http://localhost:3000/user/settings/keys) it seems as if SSH keys are for access, and only GPG keys are for signing. Perhaps this could be re-worked so the top box is for "Access keys" (being SSH or GPG) and the bottom could be for signing keys (being SSH or GPG) and some further explanation on the page about the needed key verification and that they are email addresses bound.
Singing SSH keys need to be verified on Gitea by running a command the UI provides, but even after this verification, commits may still show as "no key found" - this can sometimes be due the trust model settings or email address associated with the commits. e.g. if you're migrating from Github it's likely your commit email address is actually masked e.g. "username@users.noreply.github.com". So for your installed and verified SSH signing key to work on Gitea, you also need to add this email address to your Gitea account. It would be nice to explain this on the UI or in a new key singing doc. It seems the only way to see what email is associated with a commit username (e.g. when migrated form github) is to hover over the username in gitea or inspect the DOM title attribute.

Gitea Version

1.22.0

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

Debian

How are you running Gitea?

Docker (rootful)

Database

SQLite

Originally created by @hozza on GitHub (Jun 16, 2024). ### Description I had some trouble using SSH key singing on Gitea. I'm adding this issue to help others who may be searching for solutions and to suggest some improvements. I'll try to contribute to these issues myself when I have the time also. 1. Access SSH key and Signing SSH key are one-and-the-same in Gitea. In Github an SSH key for signing can be separate from the SSH key used for access. This means that if you migrate from Github where you used separate access and signing keys, it's required that your singing key must now be used for git clone/pull/push access too within Gitea and there's no way to prevent this. This is not the case with GPG singing though. 2. Unclear "Unverified" message on singing SSH keys. This is being worked on in #20608. Essentially, even once you've uploaded the signing SSH key, it will still say "no known key found" when it should say "found key is unverified" or something of that nature. 3. During a PR merge, even when singing ssh keys are working, a PR merge from the web on Gitea will still say "There is no key available to sign this commit.". I don't remember how Github handles this, but gitea could explain why it cannot sign (it doesn't have the priv key?). 4. UX & Docs. The docs are pretty sparse on SSH keys, and SSH key singing as they only referencing GPG singing. On the key settings (http://localhost:3000/user/settings/keys) it seems as if SSH keys are for access, and only GPG keys are for signing. Perhaps this could be re-worked so the top box is for "Access keys" (being SSH or GPG) and the bottom could be for signing keys (being SSH or GPG) and some further explanation on the page about the needed key verification and that they are email addresses bound. 5. Singing SSH keys need to be verified on Gitea by running a command the UI provides, but even after this verification, commits may still show as "no key found" - this can [sometimes be due the trust model settings](https://github.com/go-gitea/gitea/issues/20597#issuecomment-1207736998) or email address associated with the commits. e.g. if you're migrating from Github it's likely your commit email address is actually masked e.g. "username@users.noreply.github.com". So for your installed and verified SSH signing key to work on Gitea, you also need to add this email address to your Gitea account. It would be nice to explain this on the UI or in a new key singing doc. It seems the only way to see what email is associated with a commit username (e.g. when migrated form github) is to hover over the username in gitea or inspect the DOM title attribute. ### Gitea Version 1.22.0 ### Can you reproduce the bug on the Gitea demo site? Yes ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System Debian ### How are you running Gitea? Docker (rootful) ### Database SQLite

GiteaMirror added the topic/commit-signing type/bug labels 2025-11-02 10:33:17 -06:00

GiteaMirror commented

2025-11-02 10:33:18 -06:00

@s-yh-china commented on GitHub (Jul 2, 2024):

and if you use noreply by gitea, like violetc@noreply.localhost, so actually, it will still show as "no key found".
you need self add it to your gitea account

@s-yh-china commented on GitHub (Jul 2, 2024): and if you use noreply by gitea, like violetc@noreply.localhost, so actually, it will still show as "no key found". you need self add it to your gitea account

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#13165