Support signed pushes

[silverwind]

Git supports signing pushes since 2.2.0, we should enable it server side if git is at least that version as it's a backwards-compatible feature. Essentially we need to configure each repo or git globally with:

[receive]
    advertisePushOptions = true
    certNonceSeed = "<uniquerandomstring>"

Maybe the UI can also indicate push signatures, but I guess that can come later.

certNonceSeed could be set to a hash derived from security.SECRET_KEY.

https://people.kernel.org/monsieuricon/signed-git-pushes
https://github.com/git/git/blob/7f7ebe054af6d831b999d6c2241b9227c4e4e08d/Documentation/RelNotes/2.2.0.txt#L81-L87

[wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf]

first of all - cheers.
I wanted to ask.
If I already have this enabled on my server, would I have to edit the app.ini config (namely the certNonceSeed value) before upgrading once this option is ready or would it leave .gitconfig unchanged (that is - working as it is)?

[silverwind]

I'm actually also wondering what happens if certNonceSeed changes on the server. Does anyone know if that will that invalidate anything?

[wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf]

You yourself as the operator would not be able to verify the validity of the old certificates with the new nonce seed.

I think it does not matter if you are just recording the certs or rejecting invalid or unsigned pushes - that's done using the current nonce seed, others would probably barely notice, since they don't have access to the nonce seed in the first place, otherwise they'd be able to forge certs.
Until you need to verify something.
At which point you'd have to recall when exactly you changed it, what was the original (and/or all of the previous values) and go about trying all your different past nonce seeds to see if the cert can finally be verified

So the seed probably shouldn't be changed in a random way as no mechanism to keep track of the changes exists (other than your pass).
Similarly to your GPG key, you don't normally change it every day.
You could maybe change it on a yearly basis knowing when it's done and saving previous values safely.

[silverwind]

Right, so ideally we should expose a option to allow users to set their own certNonceSeed to allow them keep the verifyability of old signatures. If there is no user-defined nonce, generate one derived from security.SECRET_KEY.

I guess if really necessary one could also expose a option to input past nonces for verification purpose, but I think in the general use case we can assume a user either sets their previous nonce or sets none at all, getting the default.

[wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf]

Right, so ideally we should expose a option to allow users to set their own certNonceSeed to allow them keep the verifyability of old signatures. If there is no user-defined nonce, generate one derived from security.SECRET_KEY.

I don't think it works like that.
It's set server-wide, like a TLS cert for a domain/service rather than for the specific user.
It's more of a mechanism for server to keep stateful-ish track of the pushes, really, and (in case you want it) to act on the info.

I guess if really necessary one could also expose a option to input past nonces for verification purpose, but I think in the general use case we can assume a user either sets their previous nonce or sets none at all, getting the default.

This would then probably be a non-standard and non-intended use of the thingy, while I agree it's a nice idea.
Still, would probably require more thought on the subject.

[wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf]

I also have no idea how hard resets are solved in the scenario of changed nonce seed, much less of an idea if we consider per-user nonce seed.
Which is probably why IMO it'd be best to first stick to the default, per-server nonce seed that is not supposed to change and maybe experiment later.

[silverwind]

I never said per-user nonce. I of course meant per-server (or if a cluster of servers, shared among them).

[wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf]

I never said per-user nonce. I of course meant per-server (or if a cluster of servers, shared among them).

right, my bad...I got the users part as general instance users, not as Gitea users == instance admins

[silverwind]

Yeah, I meant admins, not actual gitea users 😉

[silverwind]

So I think we can close this, the preferred way should be to configure it in /etc/gitconfig and the git server process will pick it up there. Docker users can mount that file into the container. No explicit support from gitea required.

[6543]

I think we should at least document it ?

[silverwind]

Hmm yes, some docs regarding this and /etc/gitconfig in general would be nice.