Ok so important update,
After reading this in the docs:
The default option will interrogate git config for commit.gpgsign option
I did some testing and found out, that you can already make gitea sign these commits with an SSH key and it's quite simple.
Issue is now that it will show the commit without a green lock in the interface when you view it:

I did confirm that this commit is signed by the SSH key I added though.

Here is what I did.

• Exec into the container
• run mkdir /data/gitea/home/.ssh
• Run ssh-keygen and create a keypair in /data/gitea/home/.ssh
• Run chown -R 1000:1000 /data/gitea/home/.ssh
• Edit /data/gitea/home/.gitconfig and add the following (add to section if it already exists):

[user]
    signingKey = /data/gitea/home/.ssh/id_ed25519.pub
[commit]
    gpgsign = true
[gpg]
    format = ssh

• Finally add the following to the app.ini

[repository.signing]
SIGNING_KEY=default
SIGNING_NAME=Gitea
SIGNING_EMAIL=git@domain.com
WIKI=always
CRUD_ACTIONS=always
MERGES=always

(not sure if SIGNING_NAME and SIGNING_EMAIL do anything in this case)

This will make gitea sign Merge/CRUD/init commit but sadly gitea will not accept it as a valid signign key and show the commits without a green lock symbol.
Is there a way already to tell gitea that this key should be "trusted" ?

Is there a way already to tell gitea that this key should be "trusted" ?

Add the ssh public key to an existing user?

Yeah that might work but doesn't seem like the "correct way".
Should be some central list that contains the trusted keys.
The canonical place would be a allowed_signers file somewhere.

I tried creating an allowed signers file in the home folder with the key inside and added

[gpg "ssh"]
        allowedSignersFile "/data/gitea/home/allowed_signers"

to the .gitconfig file - but this changes nothing. Gitea seems not to be able to use this yet.

Seems like this is more complicated.., I also try to figure out how this works.

The first time I used the wrong .gitconfig, my docker image had two of them...

Yeah that might work but doesn't seem like the "correct way".
Should be some central list that contains the trusted keys.
The canonical place would be a allowed_signers file somewhere.

I checked the source code and debugger, this does only work correctly for a single user instance of Gitea. Very fragile.

ssh signed commit can only be verified if

1. committer email is known to an instance user
2. that exact user has the ssh public key explicitly added (allowedSignersFile is not used git cat-file commit sha is used to extract the signature and verify without git)
3. the public key of the user has been "verified" using the button in settings ( I missed this )

With the setup you described 2. can not be satisfied for more than one user...., so indeed we need changes to gitea. However not sure how to proceed.

• make gitea not use the current user as committer and use user Gitea or instance admin or user defined (so they show up similar to GitHub signed commits on gitea.com, that committer is GitHub not the user) works see next comment
• allow to configure a ssh private key per user in settings and database (can not be backported to 1.24), could be an complex enhancement
  • maybe allow to auto generate one where the user do not need the private key
  • EDIT SSH Trust could be extended here

    gitea/services/asymkey/commit.go

    Line 363 in e67f74e

    func ParseCommitWithSSHSignature(ctx context.Context, c *git.Commit, committer *user_model.User) *asymkey_model.CommitVerification {

  • using a global signing key here is not practicable to add to other forges, for Gitea this would be a security problem as we can not only allow commit validation without granting push

• make gitea not use the current user as committer and use user Gitea or instance admin or user defined (so they show up similar to GitHub signed commits on gitea.com, that committer is GitHub not the user)

I found how to resolve this part in Gitea 1.23

DEFAULT_TRUST_MODEL = committer

So I now have

[repository.signing]
SIGNING_KEY = default
INITIAL_COMMIT = always
CRUD_ACTIONS = always
WIKI = always
MERGES = always
DEFAULT_TRUST_MODEL = committer

Maybe collaboratorcommitter is better here, need to look around.

I don't think it is a problem to create a user called Gitea that has the signing key verified.

looks good on my end now, thanks for pointing me to the correct git home.

Nice find,
It still bugs me that I'd have to create a "dummy" user for this and also that the name of this user is not changeable.
Feels like a bad hack what we're doing here so for now I'll wait on some official Word from the maintainers on how they think this should work.

the name of this user is not changeable.

It is changeable or do I miss something?, both username and email.

in /data/gitea/home/.gitconfig (of docker image)
Should be the following values for SIGNING_KEY = default without SIGNING_EMAIL and SIGNING_NAME (for default they are read from git config)

[user]
    email = 
    name =

Yes you are correct, I didn't change both values.

I used a debugger and looking at the source code, IMHO this needs documentation

Thanks for your time.
So this is barely usable and definitely needs documentation and/or some work done to make it easier and more robust.
I still think a solution which doesn't require the creation of another account would be a lot better.