I’m trying to figure out how these settings work, I basically want to reject commits from collaborators that “don’t exist”, and I thought signed with ssh-key would fix that.
I use the GitHub Desktop client and everything in my .gifconfig file is for Github usage.
If I clone a repository from Gitea, it works I see the code and commit changes, but they are shown as “My Github Username” instead, and I can’t click the username.
If I change my username and email in the .gitconfig file I get the correct name and can click it.
(testuser is a collaborator on the repository)
I’ve tried every option of the Signing Verification Settings, but I can still commit as a username/email that does not exist in Gitea. And I would like to prevent that, but cannot figure it out.
Do you have branch protection setup with “Required Signed Commits”? If you do and it’s not working, I think it may just not be something that is possible/implemented currently.
Workaround would be to require developers to use developer branches based on master, then create pull requests for review to merge into master. During review process, trusted individual/team will verify that signature is marked as ‘trusted’ by Gitea otherwise reject merge request. Developers would be prevented from merging merge requests and pushing to master via branch protections.
Could also probably do trust verification using Gitea Actions, but that might be more work setting it up than just doing it manually.
Branch Protection was what I was looking for, got what I wanted thanks to it.
I still don’t quite know what the options under “Signing Verification Settings” do.
In the image above, I try each setting thinking something might change?
(probably a language barrier, english is not my first langauge)
I think the Signing Verification Settings control whether the commit gets a green lock “trusted” icon next to the commit SHA1, or a yellow broken lock (not certain what it looks like) “untrusted” icon next to the commit SHA1.
I remove the Branch Protection and tested all the Signing Verification Settings options without a key and then with a unverified key. They look the same.
Ether way I’m glad I got the result I wanted with Branch Protection, but it would be interesting to know what Signing Verification Settings does
