Cannot merge using "Rebase and fast-forward" when requiring signed commits

[Mo0rBy]

Description

I am trying to setup up a bunch of repos so that any committers must push signed commits to their feature branch before they are able to merge to main.

I have set the main branch to have branch protections that "Require signed commits" and I have created a PR with a signed commit.
The only merge strategy allowed on the repository is "Rebase and fast-forward", meaning that no extra commits are to be created when merged, just fast forward the main branch to the HEAD of the branch being merged (I like this strategy to keep a clean commit history).

I would expect that only the commits I have pushed would need to be signed and verified (which they are), but it looks like I may need to setup the Gitea signing key as well (even though no merge commit is to be created with this merge strategy).

I have tried using every Trust model setting and they all have the same result.

It is possible that I'm configuring something incorrectly as this is the 1st time I've tried to setup signed commits on any remote Git server, so I'm happy to try a few suggestions if anyone has any.

Gitea Version

1.23.8

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

Git Version

2.47.2

Operating System

Amazon Linux

How are you running Gitea?

Running Gitea in an AWS EKS cluster installed using the Helm chart (v12.0.0)

Database

PostgreSQL

[Mo0rBy]

I don't think this should be labelled as a bug now, but I have other issues that should be described somewhere, so I'm going to add more info to this issue, please tell me to move it somewhere else if you want.

Thank you to @TheFox0x7 & @techknowlogick for your advice on the Discord server.

So I set up a server GPG key, following the instructions documented here: https://docs.gitea.com/1.23/administration/signing#general-configuration

I then go an error message stating something like "public key not associated to user account" (I can't remember the exact wording and didn't get a screenshot, sorry). I correctly inferred that I needed to add a public GPG key to my account, so I did that and now I get a new error: "You must have two factor authentication enabled to have commits signed."

The problem with this is that I use an external OAuth source for all my Gitea server's user accounts, and therefore I cannot enable 2FA for my users. I also already have a mandatory MFA code for my SSO OAuth accounts, so we do technically have 2FA, just not Gitea 2FA.
I was pointed towards the "Skip local 2FA" option in the OAuth source settings, so I checked the box, but I get the same result.

So I'm still not sure how to get commit signing to work on my setup.

If it means anything, I have my local .gitconfig setup to use my SSH key for commit signing and I have documneted how to set this up for my users. I've done it this way because I think it will be easier for my users to setup their SSH key (which they will already have associated to their accounts in order to clone, push, pull, etc.) as the signing key, instead of messing around with GPG keys. Some of my users are not technical enough to understand this stuff, they just want to dev and test apps, they only know how to code, not how to use a computer.

So to summarise my setup (that I can't get commit signing to work with) and what I would find ideal:

1. all accounts log in using external OAuth source
2. external OAuth source has a mandatory MFA code
3. all users use an SSH key to clone, push, pull, etc.
4. would be ideal to use SSH keys for commit signing
5. would be ideal to not set a signing key on the server, all commits should be signed by a user (I would be ok with using fast-forward only merge strategy to achieve this)
6. signed commits are only required at merge time (to a protected branch that requires signed commits, I don't want to force people to push signed commits to feature branches)

I also think there should be some more documentation surrounding this topic as well because I think I've bumped into quite a few things that aren't documented, such as requiring 2FA to sign commits.
Unless you think this is general commit signing knowledge that I should know before trying to implement it.
This is my first time doing it so I could just be being an idiot.

Thanks for taking the time to read this.

[Mo0rBy]

I was going through the source code and I suddenly realised that the default settings for repository.signing.MERGES include twofa on the config cheat sheet: pubkey, twofa, basesigned, commitssigned: [never, pubkey, twofa, approved, basesigned, commitssigned, always].

So I'm gonna try playing with those settings tomorrow (it's 10:48 pm and I'm going to sleep).

[Mo0rBy]

I figured it out, I had to play with the MERGES setting a bit.

I still think there should be some more documentation on the commit signing settings though, but I will say these troubles are mostly down to me not understanding commit signing correctly.

I will close this issue now.