Gitea: Option to Sign gitea merges with pgp

[6543]

smal note for an idear: sign gitea merges

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

[lunny]

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

[zeripath]

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

[zeripath]

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

[jolheiser]

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

[6543]

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

[6543]

Somebody any experience with openpgpjs?

[zeripath]

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.

[sapk]

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.

[zeripath]

@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]

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]

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]

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.