Support signed pushes #6265

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented on GitHub (Nov 12, 2020):

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.

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented on GitHub (Nov 12, 2020): 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.

GiteaMirror commented

@silverwind commented on GitHub (Nov 12, 2020):

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.

@silverwind commented on GitHub (Nov 12, 2020): 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.

GiteaMirror commented

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented on GitHub (Nov 12, 2020):

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 commented on GitHub (Nov 12, 2020): > 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.

GiteaMirror commented

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented on GitHub (Nov 12, 2020):

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.

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented on GitHub (Nov 12, 2020): 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.

GiteaMirror commented

@silverwind commented on GitHub (Nov 12, 2020):

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

@silverwind commented on GitHub (Nov 12, 2020): I never said per-user nonce. I of course meant per-server (or if a cluster of servers, shared among them).

GiteaMirror commented

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented on GitHub (Nov 12, 2020):

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

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented on GitHub (Nov 12, 2020): > 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

GiteaMirror commented

@silverwind commented on GitHub (Nov 12, 2020):

Yeah, I meant admins, not actual gitea users 😉

@silverwind commented on GitHub (Nov 12, 2020): Yeah, I meant admins, not actual gitea users 😉

GiteaMirror commented

@silverwind commented on GitHub (Sep 1, 2021):

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.

@silverwind commented on GitHub (Sep 1, 2021): 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.

GiteaMirror commented

@6543 commented on GitHub (Sep 1, 2021):

I think we should at least document it ?

@6543 commented on GitHub (Sep 1, 2021): I think we should at least document it ?

GiteaMirror commented

@silverwind commented on GitHub (Sep 2, 2021):

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

@silverwind commented on GitHub (Sep 2, 2021): Hmm yes, some docs regarding this and `/etc/gitconfig` in general would be nice.

GiteaMirror commented

@silverwind commented on GitHub (Sep 2, 2021):

Testing this again, I think we can improve the error message seen when signed push is not enabled in gitconfig:

$ git push --signed gitea master
fatal: the receiving end does not support --signed push
fatal: the remote end hung up unexpectedly
Gitea: Internal error

Compare to GitHub which also does not support signed push but does not show the latter two messages:

$ git push --signed github master
fatal: the receiving end does not support --signed push

@silverwind commented on GitHub (Sep 2, 2021): Testing this again, I think we can improve the error message seen when signed push is not enabled in gitconfig: ``` $ git push --signed gitea master fatal: the receiving end does not support --signed push fatal: the remote end hung up unexpectedly Gitea: Internal error ``` Compare to GitHub which also does not support signed push but does not show the latter two messages: ``` $ git push --signed github master fatal: the receiving end does not support --signed push ```

GiteaMirror commented

@a1012112796 commented on GitHub (Nov 9, 2021):

maybe we can provide option to check and block unsigned git push, which is similar with "require signed commits"

@a1012112796 commented on GitHub (Nov 9, 2021): maybe we can provide option to check and block unsigned git push, which is similar with "require signed commits"

GiteaMirror commented

@Mikaela commented on GitHub (Jan 16, 2022):

Is the procedure the same for SSH signed pushes or are those even a thing?

Edit: the answer appears to be yes, as long as the server has a SSH-signing capable git version.

@Mikaela commented on GitHub (Jan 16, 2022): Is the procedure the same for SSH signed pushes or are those even a thing? Edit: the answer appears to be yes, as long as the server has a SSH-signing capable git version.

GiteaMirror commented

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented on GitHub (Mar 8, 2022):

Is the procedure the same for SSH signed pushes or are those even a thing?

Edit: the answer appears to be yes, as long as the server has a SSH-signing capable git version.

I think this is a perfectly valid question, it'd perhaps be nice to have this mentioned in the docs.

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented on GitHub (Mar 8, 2022): > Is the procedure the same for SSH signed pushes or are those even a thing? > > Edit: the answer appears to be yes, as long as the server has a SSH-signing capable git version. I think this is a perfectly valid question, it'd perhaps be nice to have this mentioned in the docs.

GiteaMirror commented

@OdinVex commented on GitHub (Mar 9, 2022):

Would prefer to be able to do it over HTTPS if possible.

@OdinVex commented on GitHub (Mar 9, 2022): Would prefer to be able to do it over HTTPS if possible.

GiteaMirror commented

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented on GitHub (Mar 10, 2022):

Would prefer to be able to do it over HTTPS if possible.

I believe there's a confusion, I'll try to clarify.
This thread discusses (commit) push signing methods, which could either be gpg or ssh (you can now sign stuff^TM using your ssh keys, too), irrespective of the actual push transfer method used, that could be either SSH or HTTP/HTTPS.

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented on GitHub (Mar 10, 2022): > Would prefer to be able to do it over HTTPS if possible. I believe there's a confusion, I'll try to clarify. This thread discusses (commit) push ***signing*** methods, which could either be `gpg` or `ssh` (you can now sign *stuff*<sup>TM</sup> using your ssh keys, too), irrespective of the actual push *transfer* method used, that could be either SSH *or* HTTP/HTTPS.

GiteaMirror commented

@silverwind commented on GitHub (Mar 10, 2022):

Exactly. I think this is a pure documentation issue. It may be possible for gitea to automatically configure git if it supports signed pushes, but I'm not sure we have interfaces for doing that.

@silverwind commented on GitHub (Mar 10, 2022): Exactly. I think this is a pure documentation issue. It *may* be possible for gitea to automatically configure `git` if it supports signed pushes, but I'm not sure we have interfaces for doing that.

GiteaMirror commented