Improve instance wide ssh commit signing

[ChristopherHX]

• Signed SSH commits can look in the UI like on GitHub, just like gpg keys today in Gitea
• No user account of the SIGNING_EMAIL required anymore to get the verified badge
• SSH format can be added in gitea config
• No gitconfig changes needed
• Set gpg.format git key for signing command
• Previously only the default gpg key had global trust in Gitea
  • SSH Signing worked before with DEFAULT_TRUST_MODEL=committer, but not with model default and manually changing the .gitconfig

e.g. the following is all needed after ssh-keygen, no trouble with installing and setting up gpg or hacking around a hidden .gitconfig for ssh key usage

[repository.signing]
SIGNING_KEY = /data/id_ed25519.pub
SIGNING_NAME = Gitea
SIGNING_EMAIL = [email protected]
SIGNING_FORMAT = ssh
INITIAL_COMMIT = always
CRUD_ACTIONS = always
WIKI = always
MERGES = always

Where /data/id_ed25519 is the private key.

TRUSTED_SSH_KEYS can be a list of additional ssh public key contents to trust for every user of this instance

Closes #34329
Related #31392

[ChristopherHX]

What do you think @brtwrst about this?

Except of an absent automatic setup this should now be even easier, by just editing a single file.

I found out that gpg supported global key verification for all users, but ssh not, this PR aims to change that.

No I have no idea how to write tests for this

[brtwrst]

That looks awesome. Makes it super simple to set up and the TRUSTED_SSH_KEYS allows for "key rotation" without losing the green checkmark on older commits. How should TRUSTED_SSH_KEYS look in the app.ini?
Like this?
TRUSTED_SSH_KEYS="ssh-ed25519 AAAA... user1@hostname", "ssh-ed25519 AAAA... user2@hostname"
Or should it be a path to a file that includes the trusted public keys?

[ChristopherHX]

I tested this like this TRUSTED_SSH_KEYS = ssh-ed25519 AAAA... and should support comma like other array like ini options.

Since the ssh keys are so simple idk if a double quote are even needed / supported.

File paths are not supported in this PR for this list.

[brtwrst]

Ok, can't wait for this to make it in :)

Thank you for your work.

[lunny]

app.example.ini needs to be updated.

[wxiaoguang]

Made some changes in c771cd6 and reverted unnecessary test changes.

I have some new questions and left some FIXMEs in code.

[wxiaoguang]

FIXME: about "signerUser"

Actually I have one more question: is it fine to use "TrustedSSHKeys" like this? For example:

1. Set SigningKey=K1, SigningEmail=Email1
2. Then rotate, set SigningKey=K2, SigningEmail=Email2, add K1 to TrustedSSHKeys
3. Now, when use K1 to verify, it knows nothing about Email1, so some "verification trust models" would always fail?

[ChristopherHX]

You are correct this is some part that is very likely incorrect, it might be better to use SIGNING_USER and SIGNING_EMAIL.

why here uses "commiterUser" as "signerUser" but below don't?

The original reason, I updated the code below to use "gpgSettings.Email" was that enabling the existing gpg git signing integration test caused failures while verifying the signer email.

I look into that tomorrow to make both use gpgSettings.Email, but the TrustedSSHKeys does not need to check if the SIGNING_FORMAT e.g. ssh to gpg migration.

some "verification trust models" would always fail?

I made a script to verify this and my answer for the time being is No.

• Step 1 auto setup gitea, with initial commit signing enabled with the first key
• Step 2 call rest apis

          await github.rest.repos.createForAuthenticatedUser({
            name: 'test-repo',
            private: false,
            auto_init: true,
            default_branch: 'main',
            trust_model: 'committer',
          })
          await github.rest.repos.createForAuthenticatedUser({
            name: 'test-repo2',
            private: false,
            auto_init: true,
            default_branch: 'main',
            trust_model: 'collaboratorcommitter',
          })
          await github.rest.repos.createForAuthenticatedUser({
            name: 'test-repo3',
            private: false,
            auto_init: true,
            default_branch: 'main',
            trust_model: 'collaborator',
          })

• Step 3 Rotate keys move old pubkey into TrustedSSHKeys
• Step 4 Open your Local Gitea

Yes how I did this here has exactly one possible odd thing in test-repo3 See here

The other trust models have no visible change before and after rotation for me, but maybe I am wrong here and there are more problems.

[wxiaoguang]

Same as the FIXME above: what we expect the "committer" and "signer" to be when using instance-wide SSH key and the rotated trusted key?

[ChristopherHX]

Here the Committer is given by the fixture e.g. committer User Two <[email protected]> 1749230009 +0200

We can assert this, I am going to update this test soon.