New check: signed commits

[laurentsimon]

there seems to be a setting under branch protection called Require signed commits which may be useful to add.
We could also have this as part of separate check when git/git#1041 is merged and operational.

@FStelzer @djmdjm do you have some rough estimate when ssh signing git/git#1041 will go live and if it will be supported as part of the branch protection setting?

[laurentsimon]

some related discussion at #223

[FStelzer]

I can't really give any indication of when this will be generally available. There is still a bit of review / discussion of specifics going on. And even if it is merged/released soon i have no idea on when github might provide the feature.
I guess when the feature made it into a git release you can open a ticket with github to ask for it. But they'll have to implement some things to manage the allowedSigners as well.

[laurentsimon]

I can't really give any indication of when this will be generally available. There is still a bit of review / discussion of specifics going on. And even if it is merged/released soon i have no idea on when github might provide the feature.
I guess when the feature made it into a git release you can open a ticket with github to ask for it. But they'll have to implement some things to manage the allowedSigners as well.

Thanks!

[laurentsimon]

duplicate #379

[laurentsimon]

landed git/git#1041!
Time to open an issue then? I'm actually wondering how a third-party would verify the commits: does GitHub make the public keys available somewhere?

[naveensrinivasan]

landed git/git#1041!
Time to open an issue then? I'm actually wondering how a third-party would verify the commits: does GitHub make the public keys available somewhere?

It is a going to take a while before it lands in GitHub

[FStelzer]

The change was merged to master. So it should be in git 2.34 which will probably release in mid november.
Regarding verification its up to github to either let the repo owner authorize keys or generate a list from users having push access to the repo. You can easily create a list yourself since github has public urls for the ssh keys:
https://github.com/laurentsimon.keys

edit: sorry misread your question. Github could publish the signers file, or you could build an individual one (a ‚trust on first use‘ feature in git will follow). Or a project could require all signed commits and then check a list into the repo itself. Who to trust can still be a personal or a projects decision.

[laurentsimon]

The change was merged to master. So it should be in git 2.34 which will probably release in mid november. Regarding verification its up to github to either let the repo owner authorize keys or generate a list from users having push access to the repo. You can easily create a list yourself since github has public urls for the ssh keys: https://github.com/laurentsimon.keys

good first step, but it is not part of the commit history. Makes it hard to retroactively validate commit history via other tooling. To decouple trust from github, may also be useful to have a transparency log for this. There's been a lot of proposal about this in the past, in particular w.r.t identities for chat apps like Signal. Seems like a natural fit for this problem... in theory :-D

edit: sorry misread your question. Github could publish the signers file, or you could build an individual one (a ‚trust on first use‘ feature in git will follow). Or a project could require all signed commits and then check a list into the repo itself. Who to trust can still be a personal or a projects decision.

agreed it's up to users.

[FStelzer]

the allowedSignersFile has a valid-before/after option for every key and is meant to be edited/appended continually.
so forges like github/gitlab/bitbucket can edit this file every time a user their access granted or revoked not by adding/removing their key but by setting the validity timestamps and adding the key again in case it gets readded.
if a user changes their key it would also just set valid-before=now() and add the new one with valid-after=now().
only if you want to invalidate all prior signatures of a key you should move it to the revokedkeys file.

this allows for verifying the history up to the point the file was created. if you deem your repo secure enough to also store this allowed signers list you can then add it to the repo and everyone can verify the whole commit history using just plain git (and the necessary ssh-keygen tool).

ideally github could default to the users already present ssh key but also allow for uploading one only used for signing (i use different keys for signing & auth).

[github-actions]

Stale issue message

[justaugustus]

(Noting the official thread for SSH signing: community/community#7744)

[github-actions]

This issue is stale because it has been open for 60 days with no activity.

[lasomethingsomething]

@spencerschrock @afmarcum and others: From our Jan 25 meeting, we said we'd close this one as a "won't do."

[spencerschrock]

Additionally this one is a duplicate of #379. Any future discussion should take place there.