Option to Sign gitea merges with pgp #3663

New Issue

GiteaMirror · 2025-11-02T05:20:59-06:00

GiteaMirror commented

2025-11-02 05:20:59 -06:00

Originally created by @6543 on GitHub (Jul 24, 2019).

smal note for an idear: sign gitea merges

Is this posible to talk to pgp throu an browser to use a smartkard?

Originally created by @6543 on GitHub (Jul 24, 2019). smal note for an idear: sign gitea merges * Is this posible to talk to pgp throu an browser to use a smartkard?

GiteaMirror added the type/proposal label 2025-11-02 05:20:59 -06:00

GiteaMirror closed this issue

2025-11-02 05:21:00 -06:00

GiteaMirror commented

2025-11-02 05:21:01 -06:00

@lunny commented on GitHub (Jul 25, 2019):

Since web browser could interactive with yubikey and etc. and yubikey could store gpg private key. I think that's possible.

@lunny commented on GitHub (Jul 25, 2019): Since web browser could interactive with yubikey and etc. and yubikey could store gpg private key. I think that's possible.

GiteaMirror commented

2025-11-02 05:21:01 -06:00

@zeripath commented on GitHub (Jul 25, 2019):

I also wonder if we could somehow use something asssociated with the 2fa system.

@zeripath commented on GitHub (Jul 25, 2019): I also wonder if we could somehow use something asssociated with the 2fa system.

GiteaMirror commented

2025-11-02 05:21:01 -06:00

@zeripath commented on GitHub (Jul 25, 2019):

I do think we need to have merges signed before we move to Gitea.com though.

@zeripath commented on GitHub (Jul 25, 2019): I do think we need to have merges signed before we move to Gitea.com though.

GiteaMirror commented

2025-11-02 05:21:01 -06:00

@jolheiser commented on GitHub (Jul 25, 2019):

I mentioned this in another issue, but it's worth noting that GitHub uses a single key for all web-flow.
This article explains that their web-flow uses a key not tied to a user, but a key tied to GitHub itself.
The key can be found at https://github.com/web-flow.gpg

@jolheiser commented on GitHub (Jul 25, 2019): I mentioned this in another issue, but it's worth noting that GitHub uses a single key for **all** web-flow. [This article](https://help.github.com/en/articles/about-commit-signature-verification) explains that their web-flow uses a key **not tied to a user**, but a key tied to GitHub itself. The key can be found at https://github.com/web-flow.gpg

GiteaMirror commented

2025-11-02 05:21:01 -06:00

@6543 commented on GitHub (Jul 26, 2019):

I woild prefere the yubikey version. But jolheiser is probably simpler to implement

@6543 commented on GitHub (Jul 26, 2019): I woild prefere the yubikey version. But **jolheiser** is probably simpler to implement

GiteaMirror commented

2025-11-02 05:21:01 -06:00

@6543 commented on GitHub (Jul 26, 2019):

Somebody any experience with openpgpjs?

@6543 commented on GitHub (Jul 26, 2019): Somebody any experience with [openpgpjs](https://openpgpjs.org/)?

GiteaMirror commented

2025-11-02 05:21:02 -06:00

@zeripath commented on GitHub (Jul 26, 2019):

So, prior to my changes to use the index without checking out - we would have got web-flow for free - although unconfigurable through docker - if the running user of the gitea program had an appropriately set up .gitconfig.

I think if we simply add -S to the git commit-tree calls then that might return.

OK it's a bit more complicated than that... but that's the gist of it.

@zeripath commented on GitHub (Jul 26, 2019): So, prior to my changes to use the index without checking out - we would have got web-flow for free - although unconfigurable through docker - if the running user of the gitea program had an appropriately set up .gitconfig. I think if we simply add `-S` to the git commit-tree calls then that might return. ---- OK it's a bit more complicated than that... but that's the gist of it.

GiteaMirror commented

2025-11-02 05:21:02 -06:00

@sapk commented on GitHub (Jul 26, 2019):

We can maybe simply call git config --global commit.gpgsign true and git config --global user.signingkey XXXXXX at startup depending of config ? And generating a key if not allready generated ? For the smartkard part it would be much harder to implement.

@sapk commented on GitHub (Jul 26, 2019): We can maybe simply call `git config --global commit.gpgsign true` and `git config --global user.signingkey XXXXXX` at startup depending of config ? And generating a key if not allready generated ? For the smartkard part it would be much harder to implement.

GiteaMirror commented

2025-11-02 05:21:02 -06:00

@zeripath commented on GitHub (Jul 26, 2019):

@sapk So I've needed to adjust the calls to git commit-tree to add -S if commit.gpgsign is true and of course implement the equivalent of git_parse_bool.

The next thing is to sort out the verification code to check if it matches the default key and mark commits as signed if so - I should check how github signs things - if they're signing stuff they might have to be the committer or the author or something like that.
Then we can add a web-flow.gpg public key endpoint to publish the gpg key.

Then we can get on with adjusting docker to create a gpg key as necessary and maybe add some more configurability to this.

@zeripath commented on GitHub (Jul 26, 2019): @sapk So I've needed to adjust the calls to `git commit-tree` to add `-S` if `commit.gpgsign` is true and of course implement the equivalent of git_parse_bool. The next thing is to sort out the verification code to check if it matches the default key and mark commits as signed if so - I should check how github signs things - if they're signing stuff they might have to be the committer or the author or something like that. Then we can add a web-flow.gpg public key endpoint to publish the gpg key. Then we can get on with adjusting docker to create a gpg key as necessary and maybe add some more configurability to this.

GiteaMirror commented

2025-11-02 05:21:02 -06:00

@zeripath commented on GitHub (Jul 26, 2019):

Aha! Github will only sign a merge if all the constituent commits were signed and won't sign web edited files either

Actually it appears weirder than that as it didn't sign: https://github.com/go-gitea/gitea/pull/7622

@zeripath commented on GitHub (Jul 26, 2019): Aha! Github will only sign a merge if all the constituent commits were signed and won't sign web edited files either --- Actually it appears weirder than that as it didn't sign: https://github.com/go-gitea/gitea/pull/7622

GiteaMirror commented

2025-11-02 05:21:03 -06:00

@zeripath commented on GitHub (Jul 27, 2019):

Right, I think we need to think seriously about when and what we want to sign.

First of all let's list the number of ways a commit can be made on the UI:

Repository initialisation
Web/API file CRUD
Web Tag and Release
PR Merges from head into base
Merges into a PR head from its base

There are a number of options:

Don't sign anything
Sign everything done on the web interface for all users at all times with a single key as per global . gitconfig
Sign depending on how the user has logged in - e.g. have they used 2fa? Trusted external db? Etc.
Sign a squashed/rebased merge if every commit in the merged is signed? (This could be combined as or/and with the above)
Sign approved merges
Only sign certain actions. It probably makes sense to always sign repository initialisation if there's a key.

@zeripath commented on GitHub (Jul 27, 2019): Right, I think we need to think seriously about when and what we want to sign. First of all let's list the number of ways a commit can be made on the UI: * Repository initialisation * Web/API file CRUD * Web Tag and Release * PR Merges from head into base * Merges into a PR head from its base There are a number of options: * Don't sign anything * Sign everything done on the web interface for all users at all times with a single key as per global . gitconfig * Sign depending on how the user has logged in - e.g. have they used 2fa? Trusted external db? Etc. * Sign a squashed/rebased merge if every commit in the merged is signed? (This could be combined as or/and with the above) * Sign approved merges * Only sign certain actions. It probably makes sense to always sign repository initialisation if there's a key.

GiteaMirror commented

2025-11-02 05:21:03 -06:00

@zeripath commented on GitHub (Jul 27, 2019):

Next I think we need to think carefully about multiple key control.

Presumably we'd like to be able to allow Organisations and/or individuals to have their own keys. There are two options:

Keys are stored on the server and commits etc are signed by the server.
Utilise openpgpjs to allow the user to sign.

If we're storing on the server: passing around private keys is not really appropriate - so these keys would have to be generated in Gitea and kept on the server if Gitea is going to sign these. We would then have to provide some way for users to sign the public keys and upload their signatures of these public keys to indicate their trust. Edit: Thinking on we could use subkeys for this - the user encrypts their private subkey with the gitea public key, which gitea can then decrypt using its private key, storing both a decrypted public key in the db and some encrypted version of the private key.

How we store the private keys is an issue. Clearly storing these keys unencrypted is not ideal. However storing them encrypted with a plaintext password stored in the db is not much better. I don't know what to do.

If using openpgpjs - we would have to generate the commit and then present the commit to the user to sign. I think it would be difficult to wire openpgpjs into the commit making process - and in any case you only sign the commit not the tree.

For both: We could provide a way of signing commits and adding them to signed branch? Given a signed commit and a non signed commit you can assert that they are of the same thing even if they have different parents. That allows a user to step through a branch and sign each commit in order.

@zeripath commented on GitHub (Jul 27, 2019): Next I think we need to think carefully about multiple key control. Presumably we'd like to be able to allow Organisations and/or individuals to have their own keys. There are two options: * Keys are stored on the server and commits etc are signed by the server. * Utilise openpgpjs to allow the user to sign. If we're storing on the server: passing around private keys is not really appropriate - so these keys would have to be generated in Gitea and kept on the server if Gitea is going to sign these. We would then have to provide some way for users to sign the public keys and upload their signatures of these public keys to indicate their trust. _Edit:_ Thinking on we could use subkeys for this - the user encrypts their private subkey with the gitea public key, which gitea can then decrypt using its private key, storing both a decrypted public key in the db and some encrypted version of the private key. How we store the private keys is an issue. Clearly storing these keys unencrypted is not ideal. However storing them encrypted with a plaintext password stored in the db is not much better. I don't know what to do. If using openpgpjs - we would have to generate the commit and then present the commit to the user to sign. I think it would be difficult to wire openpgpjs into the commit making process - and in any case you only sign the commit not the tree. For both: We could provide a way of signing commits and adding them to signed branch? Given a signed commit and a non signed commit you can assert that they are of the same thing even if they have different parents. That allows a user to step through a branch and sign each commit in order.

GiteaMirror referenced this issue

2025-11-02 12:24:46 -06:00

[PR #3663] [MERGED] Update markbates/goth libary to fix OAuth2 support (#3661) #17035

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#3663