Add option to only allow 🔐 signed commits for a repository #5042

New Issue

GiteaMirror · 2025-11-02T06:12:15-06:00

GiteaMirror commented

2025-11-02 06:12:15 -06:00

Originally created by @alexanderadam on GitHub (Mar 10, 2020).

Gitea version (or commit ref): 1.12.0+dev-3-g9269b7f62
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL): reproducible on all repositories

Description

It would be nice if someone could enforce to have only signed commits on a repository.
Somebody else described this fully on GitLab issue 3737.

Maybe in that case Gitea should also generate an own key that will sign all PR in the GUI. Like described in GitLab issue 19185.

Also I'm not sure whether the current Docker image is able too handle GPG at all?

PS: I hope "stealing" ideas from GitLab issues is okay?

Originally created by @alexanderadam on GitHub (Mar 10, 2020). - Gitea version (or commit ref): `1.12.0+dev-3-g9269b7f62` - Can you reproduce the bug at https://try.gitea.io: - Yes (provide example URL): reproducible on all repositories ## Description It would be nice if someone could enforce to have only signed commits on a repository. [Somebody else described this fully on GitLab issue 3737](https://gitlab.com/gitlab-org/gitlab/issues/3737). Maybe in that case Gitea should also generate an own key that will sign all PR in the GUI. Like described in [GitLab issue 19185](https://gitlab.com/gitlab-org/gitlab/issues/19185#proposal). Also I'm not sure [whether the current Docker image is able too handle GPG at all](https://github.com/go-gitea/gitea/issues/10682#issuecomment-596992683)? **PS:** I hope "stealing" ideas from GitLab issues is okay?

GiteaMirror added the type/proposal label 2025-11-02 06:12:15 -06:00

GiteaMirror closed this issue

2025-11-02 06:12:16 -06:00

GiteaMirror commented

2025-11-02 06:12:16 -06:00

@zeripath commented on GitHub (Mar 11, 2020):

We already can sign every commit from the UI.

You can enforce signing on protected branches too. Enforcing signing on all branches is not currently supported but could be done. (We'd allow pr commits to be unsigned as those could be signed later)

You can get the docker to sign - it's just not documented as we don't know the best way to do it.

What we don't enforce is a trust scheme. This is probably more important than just enforcing signing. We verify commits are signed with keys that are in Gitea but that doesn't mean that the key should be trusted.

There are at least 5 different trust schemes I can imagine:

Verification only
GitHub-style verification (committer=signer) - this also needs support with our merging methods as GitHub will currently mark our signed merged commits unverified.
Gitea root/Team member/Collaborator Gitea keys
Explicit pubkeyring.gpg in repository - likely verify against contents of this at HEAD of master only.
Pubkeyring stored in Gitea UI.

We also need some way of doing what I am calling web-sign too. (That is the commit is presented back to the user on the UI for them locally to sign.) This requires some more thought as the commits to be signed need to go somewhere temporarily before they're signed - meaning they will need some clean up control too. The signing user would likely need the ability to inspect the tree to ensure that they're signing what they think they're signing too.

@zeripath commented on GitHub (Mar 11, 2020): We already can sign every commit from the UI. You can enforce signing on protected branches too. Enforcing signing on all branches is not currently supported but could be done. (We'd allow pr commits to be unsigned as those could be signed later) You can get the docker to sign - it's just not documented as we don't know the best way to do it. What we don't enforce is a trust scheme. This is probably more important than just enforcing signing. We verify commits are signed with keys that are in Gitea but that doesn't mean that the key should be trusted. There are at least 5 different trust schemes I can imagine: * Verification only * GitHub-style verification (committer=signer) - this also needs support with our merging methods as GitHub will currently mark our signed merged commits unverified. * Gitea root/Team member/Collaborator Gitea keys * Explicit pubkeyring.gpg in repository - likely verify against contents of this at HEAD of master only. * Pubkeyring stored in Gitea UI. We also need some way of doing what I am calling web-sign too. (That is the commit is presented back to the user on the UI for them locally to sign.) This requires some more thought as the commits to be signed need to go somewhere temporarily before they're signed - meaning they will need some clean up control too. The signing user would likely need the ability to inspect the tree to ensure that they're signing what they think they're signing too.

GiteaMirror commented

2025-11-02 06:12:17 -06:00

@lumio commented on GitHub (Jul 20, 2020):

It would be great to enforce signed commits on the push hook already by default, letting a push fail if not all commits are signed correctly

@lumio commented on GitHub (Jul 20, 2020): It would be great to enforce signed commits on the push hook already by default, letting a push fail if not all commits are signed correctly

GiteaMirror commented

2025-11-02 06:12:17 -06:00

@zeripath commented on GitHub (Oct 14, 2020):

This is enforceable using protected branches and therefore I'm going to close this.

@zeripath commented on GitHub (Oct 14, 2020): This is enforceable using protected branches and therefore I'm going to close this.

GiteaMirror referenced this issue

2025-11-02 14:25:01 -06:00

[PR #5042] [MERGED] UX + Security current user password reset #17607

Sign in to join this conversation.