gpg sign your commits

[zetok]

gpg sign your commits

[urras]

Will do, I've notified @zetok and @holgersson32644 to do the same.

[l29ah]

hasufell, how do you check those signatures btw?

[l29ah]

urras, what do you actually denote signing a commit?

[urras]

@l29ah Using git log --show-signature, you can verify the author of the Git commits

[l29ah]

@urras sure, but different people seem to mean different things when they sign a commit.

[hasufell]

The issue title says "gpg sign" and the provided link in the first post shows how it's done. I don't see how that can be misunderstood.

[l29ah]

The link doesn't clarify on what do they mean. It seems like popular interpretations are "signature verifies that the signer is the author of the changeset" and "same + signer trusts all the commits done before his commit".

[hasufell]

signer trusts all the commits done before his commit

That doesn't make sense for non-merge commits and is not my job. I take responsibility only for my own commits, unless I pull someone elses changes.

[l29ah]

But Linus and people implementing the user-side validation think different:
http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html
https://aur.archlinux.org/packages/pa/parcimonie-sh-git/PKGBUILD
So it seems the signing policy should be explicitly noted somewhere or so.

[hasufell]

But Linus and people implementing the user-side validation think different

I don't see any indication of that in Linus posts.

Linux is developed in a hiearchy manner and applies to exactly what I described in my previous post. You take responsibility of other commits ONLY if you MERGE them. And that's the only way to propagate patches up to Linus tree. There is no one who has direct access to Linus tree except Linus.

[l29ah]

… and his hoster. Just like in your project, but you have more than one valid pusher; that doesn't change the point.
Anyway, what's the correct way to verify your repo contents can be trusted if i trust the (keys of) three of you, according to your model?

[l29ah]

Three of the devs, I mean.

[hasufell]

… and his hoster

The hoster cannot push with a valid gpg key.

but you have more than one valid pusher

As a user, you have to trust all of the pushers, obviously. Any pull request goes through at least one of them. So it's enough to check for the signatures of those pushers.

Signed tags are usually used to review the whole state of a repository and mark it's integrity, but they don't make sense for overlays. If you want to automate the signature verification, write a script.

[l29ah]

So what should the script do?

[hasufell]

An incomplete example what it could do. Simple shell stuff.

git log --committer="urras" --committer="Zetok Zalbavar" --pretty="format:%h %an %G?" fcd9a208515e6aff8bf23c0d706a98c954e71050..HEAD | grep '.* [NBU]$'

[l29ah]

I don't see the criteria of validity from your example.

[hasufell]

I don't see the criteria of validity from your example.

Read the git-log manpage.

[l29ah]

It doesn't specify how do i assert the validity of the repo.

[hasufell]

It doesn't specify how do i assert the validity of the repo.

I gave you a working script that prints out all non-trusted commits. I'm not going to explain every piece of it. That's what the manpage is for.

[l29ah]

So do you mean git log --committer="urras" --committer="Zetok Zalbavar" --pretty="format:%h %an %G?" fcd9a208515e6aff8bf23c0d706a98c954e71050..HEAD | grep -q '.*[NBU]$' && echo untrusted || echo trusted?

[hasufell]

A more interesting problem is the following:
If you only trust the repository maintainers and only check their commits for validity, then you would still need to verify that any commit that's not done by those people are part of a merge. (imagine somebody hacked github again and committed straight to the repo... my above script wouldn't be able to catch that case)

There are several ways to fix this problem:

• write a script that does this magic automatically and only verifies branch 'A' of a merge. This requires that there are no fast-forward merges! So it wouldn't only validate commits from the pushers, but any commit, as long as they are normal commits or in case of a merge branch 'A'. But I currently have no implementation for this. Afais this can't be done with a bash oneliner.
• don't do merges at all, use 'git am' instead, so we wouldn't have any comitter except those that have direct push access. Git allows separation of committer and author, so this is no problem. However, in this case we wouldn't have the signature of the author, but only of the committer. This isn't a trust issue, but rather an information issue (you can't verify the identity of the author yourself).

[hasufell]

So, here is the script that checks all commit signatures in a specific range except those that are part of a merged branch (but the merge commit is checked ofc).

git show -q --pretty="format:%h %an %G?" $(git rev-list --first-parent 0255e9ab84eb12784c054a4fd681333348f5912a..HEAD) | grep '.* [NBU]$'

This means:

• if you do fast-forward merges in this repository, then the merged commits have to be signed by the repository maintainers! So best not doing fast-forward merges at all. Enforce merge commits via git merge --no-ff.
• pull requests from other people don't necessarily need signed commits, although it's nice to have them signed
• applying pull request manually via git am is also fine, since the committer is the one who signs, not the author

Something similar will probably be done via update hooks for the gentoo git tree (if it ever comes).

[hasufell]

@urras do you have a complete list of people who have push access and their public gpg keys?

We could then add some instructions to the readme how to automatically validate the signatures.

[l29ah]

@hasufell so it will succeed if the tree is totally fake w/o any signature whatsoever.

By the way, ‰ gpg --recv-key 0x53137C3033F09008
gpg: requesting key 0x53137C3033F09008 from hkps server hkps.pool.sks-keyservers.net
gpgkeys: key 53137C3033F09008 not found on keyserver
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0

[hasufell]

so it will succeed if the tree is totally fake w/o any signature whatsoever.

no.

[urras]

My PGP key is at https://pgp.mit.edu/pks/lookup?op=get&search=0x9DD9AB20E51227D2
I'm CCing @zetok and @holgersson32644 to get them to add their keys to this issue

[zetok]

https://pgp.mit.edu/pks/lookup?op=get&search=0x53137C3033F09008

[holgersson32644]

https://pgp.mit.edu/pks/lookup?op=get&search=0xE55E95E8220F34D7
(The key running until 2017.)

[urras]

PGP keys were added to AUTHORS in 61489b5