Skip to content

SSH key commit signing #31392

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
hozza opened this issue Jun 16, 2024 · 1 comment
Open

SSH key commit signing #31392

hozza opened this issue Jun 16, 2024 · 1 comment

Comments

@hozza
Copy link

hozza commented 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 More descriptive message when signing key recognised by unverified #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 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. "[email protected]". 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

@hozza hozza added the type/bug label Jun 16, 2024
@s-yh-china
Copy link

and if you use noreply by gitea, like [email protected], so actually, it will still show as "no key found".
you need self add it to your gitea account

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants