Sign merges, CRUD, Wiki and Repository initialisation with gpg key #7631

zeripath · 2019-07-26T11:53:49Z

zeripath commented

2019-07-26 11:53:49 +00:00

This PR fixes #7598 by providing a configurable way of signing commits across the Gitea instance. Per repository configurability and import/generation of trusted secure keys is not provided by this PR - from a security PoV that's probably impossible to do properly. Similarly web-signing, that is asking the user to sign something, is not implemented - this could be done at a later stage however.

Features

If commit.gpgsign is set in .gitconfig sign commits and files created through repofiles. (merges should already have been signed.)
Verify commits signed with the default gpg as valid
Signer, Committer and Author can all be different
- Allow signer to be arbitrarily different - We still require the key to have an activated email on Gitea. A more complete implementation would be to use a keyserver and mark external-or-unactivated with an "unknown" trust level icon.
Add a signing-key.gpg endpoint to get the default gpg pub key if available
- Rather than add a fake web-flow user I've added this as an endpoint on /api/v1/signing-key.gpg
- Try to match the default key with a user on gitea - this is done at verification time
Make things configurable?
- app.ini configuration done
- when checking commits are signed need to check if they're actually verifiable too
Add documentation

I have decided that adjusting the docker to create a default gpg key is not the correct thing to do and therefore have not implemented this.

This PR fixes #7598 by providing a configurable way of signing commits across the Gitea instance. Per repository configurability and import/generation of trusted secure keys is not provided by this PR - from a security PoV that's probably impossible to do properly. Similarly web-signing, that is asking the user to sign something, is not implemented - this could be done at a later stage however. ## Features - [x] If commit.gpgsign is set in .gitconfig sign commits and files created through repofiles. (merges should already have been signed.) - [x] Verify commits signed with the default gpg as valid - [x] Signer, Committer and Author can all be different - [x] Allow signer to be arbitrarily different - We still require the key to have an activated email on Gitea. A more complete implementation would be to use a keyserver and mark external-or-unactivated with an "unknown" trust level icon. - [x] Add a signing-key.gpg endpoint to get the default gpg pub key if available - Rather than add a fake web-flow user I've added this as an endpoint on /api/v1/signing-key.gpg - [x] Try to match the default key with a user on gitea - this is done at verification time - [x] Make things configurable? - app.ini configuration done - [x] when checking commits are signed need to check if they're actually verifiable too - [x] Add documentation I have decided that adjusting the docker to create a default gpg key is not the correct thing to do and therefore have not implemented this.

👍 9 🎉 7

codecov-io commented

2019-07-26 12:26:08 +00:00

(Migrated from github.com)

Codecov Report

Merging #7631 into master will increase coverage by 0.08%.
The diff coverage is 51.17%.

@@            Coverage Diff             @@
##           master    #7631      +/-   ##
==========================================
+ Coverage   41.74%   41.82%   +0.08%     
==========================================
  Files         512      517       +5     
  Lines       67014    67659     +645     
==========================================
+ Hits        27974    28300     +326     
- Misses      35443    35734     +291     
- Partials     3597     3625      +28

Impacted Files	Coverage Δ
modules/git/repo.go	`56.5% <ø> (ø)`	⬆️
modules/setting/repository.go	`51.42% <ø> (ø)`	⬆️
modules/structs/hook.go	`6.66% <ø> (ø)`	⬆️
routers/api/v1/misc/signing.go	`0% <0%> (ø)`
modules/git/repo_tree.go	`36.61% <0%> (ø)`	⬆️
routers/api/v1/api.go	`73.08% <100%> (+0.08%)`	⬆️
modules/repofiles/temp_repo.go	`71.07% <100%> (+0.63%)`	⬆️
routers/api/v1/convert/convert.go	`81.73% <100%> (+0.32%)`	⬆️
modules/git/utils.go	`69.49% <31.25%> (-14.23%)`	⬇️
modules/git/commit.go	`51.17% <40%> (-0.19%)`	⬇️
... and 25 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cea8ea5...7a01822. Read the comment docs.

# [Codecov](https://codecov.io/gh/go-gitea/gitea/pull/7631?src=pr&el=h1) Report > Merging [#7631](https://codecov.io/gh/go-gitea/gitea/pull/7631?src=pr&el=desc) into [master](https://codecov.io/gh/go-gitea/gitea/commit/cea8ea5ae64bbb287ed7011c6fc2e51ccdfb9cb3?src=pr&el=desc) will **increase** coverage by `0.08%`. > The diff coverage is `51.17%`. [![Impacted file tree graph](https://codecov.io/gh/go-gitea/gitea/pull/7631/graphs/tree.svg?width=650&token=t1G57YGbPy&height=150&src=pr)](https://codecov.io/gh/go-gitea/gitea/pull/7631?src=pr&el=tree) ```diff @@ Coverage Diff @@ ## master #7631 +/- ## ========================================== + Coverage 41.74% 41.82% +0.08% ========================================== Files 512 517 +5 Lines 67014 67659 +645 ========================================== + Hits 27974 28300 +326 - Misses 35443 35734 +291 - Partials 3597 3625 +28 ``` | [Impacted Files](https://codecov.io/gh/go-gitea/gitea/pull/7631?src=pr&el=tree) | Coverage Δ | | |---|---|---| | [modules/git/repo.go](https://codecov.io/gh/go-gitea/gitea/pull/7631/diff?src=pr&el=tree#diff-bW9kdWxlcy9naXQvcmVwby5nbw==) | `56.5% <ø> (ø)` | :arrow_up: | | [modules/setting/repository.go](https://codecov.io/gh/go-gitea/gitea/pull/7631/diff?src=pr&el=tree#diff-bW9kdWxlcy9zZXR0aW5nL3JlcG9zaXRvcnkuZ28=) | `51.42% <ø> (ø)` | :arrow_up: | | [modules/structs/hook.go](https://codecov.io/gh/go-gitea/gitea/pull/7631/diff?src=pr&el=tree#diff-bW9kdWxlcy9zdHJ1Y3RzL2hvb2suZ28=) | `6.66% <ø> (ø)` | :arrow_up: | | [routers/api/v1/misc/signing.go](https://codecov.io/gh/go-gitea/gitea/pull/7631/diff?src=pr&el=tree#diff-cm91dGVycy9hcGkvdjEvbWlzYy9zaWduaW5nLmdv) | `0% <0%> (ø)` | | | [modules/git/repo\_tree.go](https://codecov.io/gh/go-gitea/gitea/pull/7631/diff?src=pr&el=tree#diff-bW9kdWxlcy9naXQvcmVwb190cmVlLmdv) | `36.61% <0%> (ø)` | :arrow_up: | | [routers/api/v1/api.go](https://codecov.io/gh/go-gitea/gitea/pull/7631/diff?src=pr&el=tree#diff-cm91dGVycy9hcGkvdjEvYXBpLmdv) | `73.08% <100%> (+0.08%)` | :arrow_up: | | [modules/repofiles/temp\_repo.go](https://codecov.io/gh/go-gitea/gitea/pull/7631/diff?src=pr&el=tree#diff-bW9kdWxlcy9yZXBvZmlsZXMvdGVtcF9yZXBvLmdv) | `71.07% <100%> (+0.63%)` | :arrow_up: | | [routers/api/v1/convert/convert.go](https://codecov.io/gh/go-gitea/gitea/pull/7631/diff?src=pr&el=tree#diff-cm91dGVycy9hcGkvdjEvY29udmVydC9jb252ZXJ0Lmdv) | `81.73% <100%> (+0.32%)` | :arrow_up: | | [modules/git/utils.go](https://codecov.io/gh/go-gitea/gitea/pull/7631/diff?src=pr&el=tree#diff-bW9kdWxlcy9naXQvdXRpbHMuZ28=) | `69.49% <31.25%> (-14.23%)` | :arrow_down: | | [modules/git/commit.go](https://codecov.io/gh/go-gitea/gitea/pull/7631/diff?src=pr&el=tree#diff-bW9kdWxlcy9naXQvY29tbWl0Lmdv) | `51.17% <40%> (-0.19%)` | :arrow_down: | | ... and [25 more](https://codecov.io/gh/go-gitea/gitea/pull/7631/diff?src=pr&el=tree-more) | | ------ [Continue to review full report at Codecov](https://codecov.io/gh/go-gitea/gitea/pull/7631?src=pr&el=continue). > **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta) > `Δ = absolute <relative> (impact)`, `ø = not affected`, `? = missing data` > Powered by [Codecov](https://codecov.io/gh/go-gitea/gitea/pull/7631?src=pr&el=footer). Last update [cea8ea5...7a01822](https://codecov.io/gh/go-gitea/gitea/pull/7631?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).

lunny reviewed 2019-07-30 01:58:12 +00:00

models/gpg_key.go

lunny commented

2019-07-30 01:58:12 +00:00

This is a bug, could we create a new PR to fix this and back port it to v1.9?

zeripath reviewed 2019-07-30 06:32:53 +00:00

models/gpg_key.go

zeripath commented

2019-07-30 06:32:53 +00:00

I actually introduced it in this pr (by accident) - it's not actually in the codebase.

zeripath commented

2019-07-31 13:08:15 +00:00

There's a problem with the current merging author and committer. They don't really work correctly.

I think the committer for these should definitely be the doer - (which they currently aren't - it's currently Gitea)

Now the author is difficult - should this be the PR author - well that doesn't necessarily match who is the author of most of these commits and isn't necessarily the owner of the headRepo. Should it be the owner of the headRepo - if that person is a user - otherwise the opener of the PR?

We should probably use the Co-Authored-By: tag in our commits.

This issue can wait for another PR. In the meantime I've just set the committer to be the same as the author

Edit2:

Just to clarify this really only matters for squash commits - this code sets the author to the PR poster and committer to the doer of the merge.

There's a problem with the current merging author and committer. They don't really work correctly. I think the committer for these should definitely be the doer - (which they currently aren't - it's currently Gitea) Now the author is difficult - should this be the PR author - well that doesn't necessarily match who is the author of most of these commits and isn't necessarily the owner of the headRepo. Should it be the owner of the headRepo - if that person is a user - otherwise the opener of the PR? We should probably use the Co-Authored-By: tag in our commits. ---- This issue can wait for another PR. In the meantime I've just set the committer to be the same as the author ---- Edit2: Just to clarify this really only matters for squash commits - this code sets the author to the PR poster and committer to the doer of the merge.

silverwind commented

2019-08-05 17:03:16 +00:00

(Migrated from github.com)

If commit.gpgsign is set in .gitconfig sign commits

Which .gitconfig file does this refer to? The server-side one of the SSH user?

current merging author and committer. They don't really work correctly

GitHub only shows the committer's gpg key if that's of any help.

> If commit.gpgsign is set in .gitconfig sign commits Which `.gitconfig` file does this refer to? The server-side one of the SSH user? > current merging author and committer. They don't really work correctly GitHub only shows the committer's gpg key if that's of any help.

zeripath commented

2019-08-06 06:12:00 +00:00

Hey @silverwind. I'm referring to .gitconfig on the server side. There are three levels of .git config on the server:

Local: referring to the contents of the config file in the git repository itself.
User: the .gitconfig in the user's home directory
Global: the global gitconfig - which off the the top of my head I don't know exactly but it's in /etc somewhere.

My code should run down each one in turn as I use git config without a specifying argument.

I'm not sure exactly what GitHub does - I'd have to check, but as far as I can see looking at the code for verify-commit and from my understanding of how it's supposed to work - you don't need to be the committer or the author to sign a commit. Neither are used to verify that the signature is correct as GPG does not parse the commit data - it simply verifies that the signature is valid for the string representation for the commit block without the gpgsign block. I suspect that it's a very common misconception that only the committer can sign the commit - it is not the case.

This makes sense because you might want to rewrite history to re-sign from a compromised key and may not be able to contact the original authors although you trust the code. The commit signature only signs the commit - so given two commits, one signed and one not - you can verify that they're talking about the same thing from tree hash even if they have different parents.

Hey @silverwind. I'm referring to .gitconfig on the server side. There are three levels of .git config on the server: * Local: referring to the contents of the config file in the git repository itself. * User: the .gitconfig in the user's home directory * Global: the global gitconfig - which off the the top of my head I don't know exactly but it's in /etc somewhere. My code should run down each one in turn as I use git config without a specifying argument. I'm not sure exactly what GitHub does - I'd have to check, but as far as I can see looking at the code for verify-commit and from my understanding of how it's supposed to work - you don't need to be the committer or the author to sign a commit. Neither are used to verify that the signature is correct as GPG does not parse the commit data - it simply verifies that the signature is valid for the string representation for the commit block without the gpgsign block. I suspect that it's a very common misconception that only the committer can sign the commit - it is not the case. This makes sense because you might want to rewrite history to re-sign from a compromised key and may not be able to contact the original authors although you trust the code. The commit signature only signs the commit - so given two commits, one signed and one not - you can verify that they're talking about the same thing from tree hash even if they have different parents.

silverwind commented

2019-08-06 08:04:42 +00:00

(Migrated from github.com)

Interesting, so supposedly, I can generate a gpg key pair for the RUN_USER and add that to any user in the UI and the commits should show up as signed and verified, right? Maybe this should be documented somewhere.

Interesting, so supposedly, I can generate a gpg key pair for the `RUN_USER` and add that to any user in the UI and the commits should show up as signed and verified, right? Maybe this should be documented somewhere.

zeripath commented

2019-08-17 09:11:31 +00:00

@sapk There are now tests for this. see integrations/gpg_git_test.go

@sapk There are now tests for this. see `integrations/gpg_git_test.go`

👍 1

silverwind (Migrated from github.com) reviewed 2019-08-21 15:51:16 +00:00

custom/conf/app.ini.sample

						
				@ -75,2 +75,4 @@

				LOCK_REASONS=Too heated,Off-topic,Resolved,Spam

				[repository.signing]

				; GPG key to use to sign commits, Defaults to the default - that is the value of git config --get user.signingkey

silverwind (Migrated from github.com) commented

2019-08-21 15:51:16 +00:00

Maybe add a comment that this uses RUN_USER's git config.

Maybe add a comment that this uses `RUN_USER`'s git config.

silverwind (Migrated from github.com) reviewed 2019-08-21 15:52:10 +00:00

custom/conf/app.ini.sample

						
				@ -77,0 +84,4 @@

				; the results of git config --get user.name and git config --get user.email respectively and can only be overrided

				; by setting the SIGNING_KEY ID to the correct ID.)

				SIGNING_NAME =

				SIGNING_EMAIL =

silverwind (Migrated from github.com) commented

2019-08-21 15:52:10 +00:00

Can these be derived from git config as well, as a default?

lunny commented

2019-09-15 14:36:42 +00:00

Please resolve the conflicts

zeripath reviewed 2019-10-09 18:56:41 +00:00

custom/conf/app.ini.sample

						
				@ -75,2 +75,4 @@

				LOCK_REASONS=Too heated,Off-topic,Resolved,Spam

				[repository.signing]

				; GPG key to use to sign commits, Defaults to the default - that is the value of git config --get user.signingkey

zeripath commented

2019-10-09 18:56:40 +00:00

Done

zeripath reviewed 2019-10-09 18:56:44 +00:00

custom/conf/app.ini.sample

						
				@ -77,0 +84,4 @@

				; the results of git config --get user.name and git config --get user.email respectively and can only be overrided

				; by setting the SIGNING_KEY ID to the correct ID.)

				SIGNING_NAME =

				SIGNING_EMAIL =

zeripath commented

2019-10-09 18:56:44 +00:00

When the SIGNING_KEY is set to default these values are not used and instead the results of: git config --get user.name and git config --get user.email are used.

I've adjusted the comments here.

When the SIGNING_KEY is set to default these values are not used and instead the results of: `git config --get user.name` and `git config --get user.email` are used. I've adjusted the comments here.

zeripath commented

2019-10-09 18:58:00 +00:00

Conflicts resolved.

zeripath commented

2019-10-13 20:01:52 +00:00

Conflicts resolved again - restored functionality for early gits.

6543 (Migrated from github.com) reviewed 2019-10-14 21:54:16 +00:00

6543 (Migrated from github.com) left a comment

also works with gpg card (yubiKey) - if a server owner use this methode to store the priv-key then stealing them is a physical akt :)

6543 (Migrated from github.com) approved these changes 2019-10-14 22:04:20 +00:00

6543 (Migrated from github.com) reviewed 2019-10-14 22:38:56 +00:00

6543 (Migrated from github.com) left a comment

@zeripath swagger doesnt show api /api/v1/signing-key.gpg
is this intended?

@zeripath swagger doesnt show api /api/v1/signing-key.gpg is this intended?

zeripath commented

2019-10-15 01:38:06 +00:00

@6543 Damn I forgot those.

zeripath commented

2019-10-15 01:42:16 +00:00

It's not actually immediately obvious what the swagger spec for these would though.

lunny reviewed 2019-10-15 01:49:28 +00:00

docs/content/doc/advanced/signing.en-us.md

lunny commented

2019-10-15 01:49:28 +00:00

Merges from Pull Requests

zeripath reviewed 2019-10-15 01:58:03 +00:00

docs/content/doc/advanced/signing.en-us.md

zeripath commented

2019-10-15 01:58:03 +00:00

I don't think we do any other merges but I take your point.

* Merges from Pull Requests

I don't think we do any other merges but I take your point. ```suggestion * Merges from Pull Requests ```

lafriks (Migrated from github.com) reviewed 2019-10-15 05:58:33 +00:00

modules/structs/hook.go

						
				@ -98,3 +98,4 @@

					Payload   string       `json:"payload"`

				}

				var (

lafriks (Migrated from github.com) commented

2019-10-15 05:58:33 +00:00

Why is Signer needed?

Why is `Signer` needed?

lafriks commented

2019-10-15 05:59:35 +00:00

(Migrated from github.com)

Otherwise LG-TM apart to comment above

zeripath reviewed 2019-10-15 06:20:32 +00:00

modules/structs/hook.go

						
				@ -98,3 +98,4 @@

					Payload   string       `json:"payload"`

				}

				var (

zeripath commented

2019-10-15 06:20:32 +00:00

The user signing a commit is not necessarily the author or committer.

lafriks (Migrated from github.com) reviewed 2019-10-15 06:48:39 +00:00

modules/structs/hook.go

						
				@ -98,3 +98,4 @@

					Payload   string       `json:"payload"`

				}

				var (

lafriks (Migrated from github.com) commented

2019-10-15 06:48:39 +00:00

Yes but does it really matter? Signature is pretty much what we need for verification

Yes but does it really matter? `Signature` is pretty much what we need for verification

zeripath reviewed 2019-10-15 11:50:00 +00:00

modules/structs/hook.go

						
				@ -98,3 +98,4 @@

					Payload   string       `json:"payload"`

				}

				var (

zeripath commented

2019-10-15 11:50:00 +00:00

It will give a reference the signers name/email address (if we can match it) - so you can look them up in a keyserver or on Gitea.

A GPG signature only contains the ID of the key that signed the signature - if you don't have a public key in your local keyring that matches that ID you can't verify the signature.

Now if Gitea has verified the signature you can figure out how it has verified the signature.

It will give a reference the signers name/email address (if we can match it) - so you can look them up in a keyserver or on Gitea. A GPG signature only contains the ID of the key that signed the signature - if you don't have a public key in your local keyring that matches that ID you can't verify the signature. Now if Gitea has verified the signature you can figure out how it has verified the signature.

zeripath commented

2019-10-15 12:07:06 +00:00

@6543 I've added swagger definitions to /signing-key.gpg

@6543 I've added swagger definitions to `/signing-key.gpg`

👍 2

lafriks (Migrated from github.com) reviewed 2019-10-15 19:18:11 +00:00

modules/structs/hook.go

						
				@ -98,3 +98,4 @@

					Payload   string       `json:"payload"`

				}

				var (

lafriks (Migrated from github.com) commented

2019-10-15 19:18:10 +00:00

But there is only 3 keys that it can be - Gitea server signing key, repo singing key or commiter signing key

zeripath reviewed 2019-10-15 19:44:50 +00:00

modules/structs/hook.go

						
				@ -98,3 +98,4 @@

					Payload   string       `json:"payload"`

				}

				var (

zeripath commented

2019-10-15 19:44:50 +00:00

Could be anyone. You can sign anyone's commit.

lafriks (Migrated from github.com) reviewed 2019-10-15 20:43:30 +00:00

modules/structs/hook.go

						
				@ -98,3 +98,4 @@

					Payload   string       `json:"payload"`

				}

				var (

lafriks (Migrated from github.com) commented

2019-10-15 20:43:30 +00:00

But it won't be verified then imho

zeripath reviewed 2019-10-15 21:04:07 +00:00

modules/structs/hook.go

						
				@ -98,3 +98,4 @@

					Payload   string       `json:"payload"`

				}

				var (

zeripath commented

2019-10-15 21:04:06 +00:00

There is no parsing of the git commit when verifying a commit - it is simply does a key with ID that matches the ID of the signature decrypt the signature to the commit.

The key that matches the signature does not need to match anyone on the commit. It simply has to be a key on the keyring.

An example:

Take a copy of the git repository
git checkout 08da6496b61341ec45eac36afcc8f94242763468 -b re-sign
git cat-file commit re-sign - Pay attention to the Committer

tree 27fee9c50528ef1b0960c2c342ff139e36ce2076
parent 07f25ad8b235c2682a36ee76d59734ec3f08c413
author Junio C Hamano <gitster@pobox.com> 1570770961 +0900
committer Junio C Hamano <gitster@pobox.com> 1570771489 +0900

Eighth batch

Signed-off-by: Junio C Hamano <gitster@pobox.com>

GIT_COMMITTER_NAME="Junio C Hamano" GIT_COMMITTER_EMAIL="gitster@pobox.com" git commit --amend -S --no-edit
git cat-file commit re-sign

tree 27fee9c50528ef1b0960c2c342ff139e36ce2076
parent 07f25ad8b235c2682a36ee76d59734ec3f08c413
author Junio C Hamano <gitster@pobox.com> 1570770961 +0900
committer Junio C Hamano <gitster@pobox.com> 1571173132 +0100
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEE0s922pXyAemQFTKrPN50Yx8Tp0gFAl2mMw4ACgkQPN50Yx8T
 p0gnjA/+KVFqjIeemZmcmDeNlAbyBaytOV3GEEUpYDWhqGah7gQpizcReE7MjbY6
 x0MHhYygzgCa7JnCAZdAVTWqRiUwRceOLiA2X+oL9dJMCdBZ5H0SW9B1BAduPk6S
 AutRbXjFnPggTS3pKdttqhIIws/FPaGxVAwBxTP0tPICCEARF+Q070Huzz7z4bMU
 rUiLQvEs7aQ4X6PRBP+/84911XhXMOJSDAMJQBQHTA/avLMXY+QT7zsam+nDH1ah
 7ZTi83AIMTUiBhIafJtEPKF7w8a5hP68x75Pcdh9zCamVOKNrcVZA3/UjcBr4jNO
 9+ho0CFA/RguRUPUJg8/XsIBcqtKBE+sPL3GwhD5w6cSX6xMj59ToCqxjmLMtR/4
 fQ6vQTh2ib8lJktb78n/VN7yOYYXMKyYocSgFzjtzT62+TAXP5uqQtCz6QSiX9l9
 mZIvLlYQyX/T7/HkV7PLCLZo0fgMHin/1VRVXeI0yA3R9aoZ+MN2PWXEUbfSzkjF
 bc1XxLr7ihm3CLEpSecVmXZNXwnkVj355/tPNf+AMIAjJFls2lZSW3p56xDvWBfa
 Z6XTD4V2ivWHbWRftA/8jknxEkIS1HPIrzXZVYujuAlH8NWRgqpPXtdVfNpf2ZZE
 JXkuSb059hF+brZVryfOGiZuIAac0kmRIjcx+kQryN+mKIgl0Cg=
 =tTjx
 -----END PGP SIGNATURE-----

Eighth batch

Signed-off-by: Junio C Hamano <gitster@pobox.com>

git verify-commit re-sign

gpg: Signature made Tue 15 Oct 2019 21:58:54 BST
gpg:                using RSA key D2CF76DA95F201E9901532AB3CDE74631F13A748
gpg: Good signature from "Andrew Thornton <art27@cantab.net>" [ultimate]

There is no parsing of the git commit when verifying a commit - it is simply does a key with ID that matches the ID of the signature decrypt the signature to the commit. The key that matches the signature does not need to match anyone on the commit. It simply has to be a key on the keyring. An example: * Take a copy of the git repository * `git checkout 08da6496b61341ec45eac36afcc8f94242763468 -b re-sign` * `git cat-file commit re-sign` - Pay attention to the Committer ``` tree 27fee9c50528ef1b0960c2c342ff139e36ce2076 parent 07f25ad8b235c2682a36ee76d59734ec3f08c413 author Junio C Hamano <gitster@pobox.com> 1570770961 +0900 committer Junio C Hamano <gitster@pobox.com> 1570771489 +0900 Eighth batch Signed-off-by: Junio C Hamano <gitster@pobox.com> ``` * `GIT_COMMITTER_NAME="Junio C Hamano" GIT_COMMITTER_EMAIL="gitster@pobox.com" git commit --amend -S --no-edit` * `git cat-file commit re-sign` ``` tree 27fee9c50528ef1b0960c2c342ff139e36ce2076 parent 07f25ad8b235c2682a36ee76d59734ec3f08c413 author Junio C Hamano <gitster@pobox.com> 1570770961 +0900 committer Junio C Hamano <gitster@pobox.com> 1571173132 +0100 gpgsig -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEE0s922pXyAemQFTKrPN50Yx8Tp0gFAl2mMw4ACgkQPN50Yx8T p0gnjA/+KVFqjIeemZmcmDeNlAbyBaytOV3GEEUpYDWhqGah7gQpizcReE7MjbY6 x0MHhYygzgCa7JnCAZdAVTWqRiUwRceOLiA2X+oL9dJMCdBZ5H0SW9B1BAduPk6S AutRbXjFnPggTS3pKdttqhIIws/FPaGxVAwBxTP0tPICCEARF+Q070Huzz7z4bMU rUiLQvEs7aQ4X6PRBP+/84911XhXMOJSDAMJQBQHTA/avLMXY+QT7zsam+nDH1ah 7ZTi83AIMTUiBhIafJtEPKF7w8a5hP68x75Pcdh9zCamVOKNrcVZA3/UjcBr4jNO 9+ho0CFA/RguRUPUJg8/XsIBcqtKBE+sPL3GwhD5w6cSX6xMj59ToCqxjmLMtR/4 fQ6vQTh2ib8lJktb78n/VN7yOYYXMKyYocSgFzjtzT62+TAXP5uqQtCz6QSiX9l9 mZIvLlYQyX/T7/HkV7PLCLZo0fgMHin/1VRVXeI0yA3R9aoZ+MN2PWXEUbfSzkjF bc1XxLr7ihm3CLEpSecVmXZNXwnkVj355/tPNf+AMIAjJFls2lZSW3p56xDvWBfa Z6XTD4V2ivWHbWRftA/8jknxEkIS1HPIrzXZVYujuAlH8NWRgqpPXtdVfNpf2ZZE JXkuSb059hF+brZVryfOGiZuIAac0kmRIjcx+kQryN+mKIgl0Cg= =tTjx -----END PGP SIGNATURE----- Eighth batch Signed-off-by: Junio C Hamano <gitster@pobox.com> ``` * `git verify-commit re-sign` ``` gpg: Signature made Tue 15 Oct 2019 21:58:54 BST gpg: using RSA key D2CF76DA95F201E9901532AB3CDE74631F13A748 gpg: Good signature from "Andrew Thornton <art27@cantab.net>" [ultimate] ```

guillep2k (Migrated from github.com) reviewed 2019-10-15 21:13:31 +00:00

modules/structs/hook.go

						
				@ -98,3 +98,4 @@

					Payload   string       `json:"payload"`

				}

				var (

guillep2k (Migrated from github.com) commented

2019-10-15 21:13:31 +00:00

@lafriks The signer can change, update, etc. their gpg key after signing. I think it's valuable to keep the actual key instead of the signer identity.

guillep2k (Migrated from github.com) reviewed 2019-10-15 21:14:27 +00:00

modules/structs/hook.go

						
				@ -98,3 +98,4 @@

					Payload   string       `json:"payload"`

				}

				var (

guillep2k (Migrated from github.com) commented

2019-10-15 21:14:26 +00:00

(And of course, @zeripath 's explanation)

zeripath reviewed 2019-10-15 21:54:23 +00:00

modules/structs/hook.go

						
				@ -98,3 +98,4 @@

					Payload   string       `json:"payload"`

				}

				var (

zeripath commented

2019-10-15 21:54:23 +00:00

So, yeah, when I discovered this I was quite surprised, but it allows you to re-sign someone else's trees affirming your continued trust in those commits even if you no longer trust their signature.

Unfortunately this changes the sha of the commit so you have to effectively rebase by doing a git filter-branch for each commit and if you do do it because a key was compromised and is no longer trustworthy you have you change your heads to use the new commit heads.

(However the tree SHA should be the same so there should be a way to get git to recognise the commits would apply.)

So, yeah, when I discovered this I was quite surprised, but it allows you to re-sign someone else's trees affirming your continued trust in those commits even if you no longer trust their signature. Unfortunately this changes the sha of the commit so you have to effectively rebase by doing a git filter-branch for each commit and if you do do it because a key was compromised and is no longer trustworthy you have you change your heads to use the new commit heads. (However the tree SHA should be the same so there should be a way to get git to recognise the commits would apply.)