git log --pretty="format:%H$t%aN$t%s$t%G?" --show-signature

git log --pretty="format:%H$t%aN$t%s$t%G?" --show-signature

[Patrick Schleizer]

Dear git mailing list,
Dear Mike Gerwitz,

according to http://mikegerwitz.com/papers/git-horror-story#script-trust
the output of:

git log --pretty="format:%H$t%aN$t%s$t%G?" --show-signature

should look like this:

-----

f72924356896ab95a542c495b796555d016cbddd       Mike Gerwitz    Yet
another foo
gpg: Signature made Sun 22 Apr 2012 01:37:26 PM EDT using RSA key ID
8EE30EAB
gpg: Good signature from "Mike Gerwitz (Free Software Developer)
<mike@mikegerwitz.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the
owner.
Primary key fingerprint: 2217 5B02 E626 BC98 D7C0  C2E5 F22B B815 8EE3 0EAB
afb1e7373ae5e7dae3caab2c64cbb18db3d96fba       Mike Gerwitz    Modified
bar    G

-----

But when I run that command, spaces are missing. (Using a user that does
not know my gpg public key for testing purposes.) See output:

-----

user2@host:/home/user/testrepo$ git log
--pretty="format:%H$t%aN$t%s$t%G?" --show-signature
gpg: Signature made Thu 04 Dec 2014 04:37:58 PM UTC using RSA key ID
77BB3C48
gpg: Good signature from "Patrick Schleizer <adrelanos@riseup.net>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the
owner.
Primary key fingerprint: 916B 8D99 C38E AF5E 8ADC  7A2A 8D66 066A 2EEA CCDA
     Subkey fingerprint: 6E97 9B28 A6F3 7C43 BE30  AFA1 CB8D 50BB 77BB 3C48
529bbc076f05c13023580ea7be7ba63aba3e9672Patrick Schleizersigned commit 2U
gpg: Signature made Thu 04 Dec 2014 04:29:32 PM UTC using RSA key ID
77BB3C48
gpg: Good signature from "Patrick Schleizer <adrelanos@riseup.net>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the
owner.
Primary key fingerprint: 916B 8D99 C38E AF5E 8ADC  7A2A 8D66 066A 2EEA CCDA
     Subkey fingerprint: 6E97 9B28 A6F3 7C43 BE30  AFA1 CB8D 50BB 77BB 3C48
ea1615ac1a9fe9f957f91f54a33a60d57828a32fPatrick Schleizersigned commitU
75e79a211963907afd3a6d2f28c3571d37140231Patrick Schleizerreal long
commit msg Please enter the commit message for your changes. Lines
starting with '#' will be ignored, and an empt
30096d1633ef22463c1a770288755ae5325f1242Patrick Schleizer2N
e7be12378d2805bebe531bd01cbec9dec1f79032Patrick Schleizerinitial commitN
(END)

-----

Any idea? Am I doing something wrong?

I am asking, because therefore Mike Gerwitz's Quote "Signature Check
Script With Web Of Trust" verification script (
http://mikegerwitz.com/papers/git-horror-story#script-trust ) does not
work for me.

Mike, could you please put your various git commit verification helper
scripts into a publicly visible?

By the way, any chance that these useful helper scripts could make their
way into the official distribution of git as a stopgap until native git
commit verification support gets improved?

Cheers,
Patrick

Re: git log --pretty="format:%H$t%aN$t%s$t%G?" --show-signature

[Mike Gerwitz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey Patrick,

On Thu, Dec 04, 2014 at 17:21:06 +0000, Patrick Schleizer wrote:
> git log --pretty="format:%H$t%aN$t%s$t%G?" --show-signature
> [...]
> But when I run that command, spaces are missing. (Using a user that does
> not know my gpg public key for testing purposes.) See output:
>
> -----
>
> user2@host:/home/user/testrepo$ git log
> --pretty="format:%H$t%aN$t%s$t%G?" --show-signature

That is because the variable `$t' is defined in my script on the
preceding line, as a tab character.  You can insert it directly using
C-V <TAB>, or $'\t' in bash.

> Mike, could you please put your various git commit verification helper
> scripts into a publicly visible?

You can use this:

  https://gitorious.org/easejs/easejs/source/ee85b058df783ffaa9f8d5ae58f9eb6d7586b0ca:tools/signchk

But note that the default value of the `chkafter' var is
ease.js-specific.

> By the way, any chance that these useful helper scripts could make their
> way into the official distribution of git as a stopgap until native git
> commit verification support gets improved?

It has since improved; I'm looking for the time to update the article,
or write a follow-up.

Git has since added other pretty formatting options as well:

  https://github.com/git/git/blob/master/Documentation/pretty-formats.txt#L140

Git v2.1.0 also added a `verify-commit' command:

  https://github.com/git/git/blob/master/Documentation/git-verify-commit.txt

I haven't used it yet.

Hope that helps.

- -- 
Mike Gerwitz
Free Software Hacker | GNU Maintainer
http://mikegerwitz.com
FSF Member #5804 | GPG Key ID: 0x8EE30EAB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJUgKJyAAoJEPIruBWO4w6rdS8QAMEtQhklDe4zXju0uc6ksqYl
aXdXhE7HcyUDl6yWXEheXH4oCRLSthS+8MPQfuY8gae1eRvyHx3rViGpMEyB8s5B
xhAQpOLVmro0QIwIZ/HGX4IKoGVq/QyqvLNR8iqnV8GXPu+ckGIG/UvrkFFSaLW8
eFUvQLbNITViVgQljCzzfptL9dQvdra0D1EXxRk8+h8Sw4vKRN54h0tqKVw5PcsT
4sFUBVwgmzILNKydFkMu1C+pDwnemhS04PtcrpmUTniOzLPhWJiZwzgDV5j9tOPq
7noLrnw0kpm6PbX90i2+uSVGmh6zgoR69h7SAZGJEiHQj4BiZetLMwxJL25o73/c
1/9tWT/7kAcpvzAjPjRMS3BqV7AVwNqTKKblCszfunS87aWLs1t/bgUg4e6x3lTJ
JxyxkKnSnn3dzntMfB9UuuJ6bdtn1pJci4Ptvl2yzKHaZv7ImV78UIuxdthtMgMn
eBawq3wm7HBMETkDDyRSpuPOEycBSnWZL2dL4Xc9IxPKDTJUvHTRUXxy4v2Juiv9
Pogao25j6EpTlOqx29Y9Y95ITw/UdQU7NjPAGFNxIZZTgjzHrcIlaEKuoHp+t6oh
s8OPhD+FMNWBFdAda+zP785sUbyF93/2xBK/HFyTUinOLn1/BJBC0FqHfeYd1hQe
cJ0rYnOtckycQv+re9hz
=+Rub
-----END PGP SIGNATURE-----

Re: [Whonix-devel] git log --pretty="format:%H$t%aN$t%s$t%G?" --show-signature

[Patrick Schleizer]

Thanks Mike!

Mike Gerwitz wrote:
>> Mike, could you please put your various git commit verification helper
>> scripts into a publicly visible?
>
> You can use this:
>
>
https://gitorious.org/easejs/easejs/source/ee85b058df783ffaa9f8d5ae58f9eb6d7586b0ca:tools/signchk
>
> But note that the default value of the `chkafter' var is
> ease.js-specific.

Do you have script somewhere in public git that also checks the web of
trust?

For your blog post it would be nice to have a ease.js unspecific one.

Otherwise I just wait for our updated blog post and/or for my distro to
upgrade to git 2.1.

Cheers,
Patrick

Re: git log --pretty="format:%H$t%aN$t%s$t%G?" --show-signature

[Junio C Hamano]

Mike Gerwitz <mikegerwitz@gnu.org> writes:

> It has since improved; I'm looking for the time to update the article,
> or write a follow-up.

Thanks for an amusing read.  We also let you merge a signed tag
these days, so that in a variant of your merge scenario #2, your
merge commit can carry your GPG signature, made when you do the "git
merge -S $other_history" to merge $other_history you obtained from
your trusted colleague, as well as the signed tag your trusted
colleague made with her GPG signature.  That way, upon seeing that
merge, a third-party can verify that the merge was made by you, and
also the history of the side branch integrated to your history with
that merge is vouched by your trustred colleague.

I am however not quite sure what conclusion you are trying to drive
at by contrasting approaches #2 and #3.  The perceived problem of
approach #2, if I am reading you correctly, is that the merge is
what you vouch for but the commits on the side branch are not signed
so there is no way for you (as the merge creator) to point fingers
to when the result of the merge turns out to be problematic.  The
argument for approach #3 would be that it would give you (as the
merge creator) somebody to point fingers to if you forced others who
ask you to pull from them to sign their commits.

But I am not sure if that is the right way to look at the bigger
picture.

Imagine you are working on a project with two branches, maint and
master.  The policy adopted by the project is to use the maint
branch to prepare for the next maintenance release, which should
never add new features.  New features are to be merged to master
for the next feature release.

And imagine that you made a mistake of merging somebody else's
branch that adds a new feature, which happens to be perfectly done
and introduces no bug, to the maint branch.  Your merge is signed by
your GPG key.

Does it absolve you from blame if you can say with certainty (thanks
to GPG keys on them) that those commits on the side branch that adds
unwanted (from 'maint' policy's point of view) new feature were made
by somebody else, because the project used the approach #3?

Not really.

How would that case be any different from the case where the side
branch you merged were buggy or even malicious?  After all, your GPG
signature carries more weight than "Yes, I did this random merge but
I did so without thinking about what damage it causes to the history
by pulling in other peoples' changes".  Or at least it should carry
more weight to your users who trust a history having your GPG
signature.  "This history is coming from Mike whom we trust" is what
your users expect, no?  When you sign your merge with "merge -S",
you are vouching for the contents of the whole tree, not just "I
made this merge, but I don't have anything to do with what it pulled
in."  It does not really matter to the end users where the changes
came from.  You are certifying that "git diff HEAD^ HEAD" after
making the merge is what you are pleased with by signing the merge.

Having said that, what approach #3 (or merging a signed tag) does
give you as the merge creator is a distrubution of trust.  You may
not have to be _so_ careful verifying "git diff HEAD^ HEAD" of the
merge when you know you can trust the side branch you are merging
into your history was done by somebody you trust.

But ultimately, the responsibility lies on the person who creates
the topmost merge and advances the tip of the history the users of
the end product of the project considers the authoritative one.

Re: git log --pretty="format:%H$t%aN$t%s$t%G?" --show-signature

[Mike Gerwitz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for the input, Junio.

On Thu, Dec 04, 2014 at 13:11:15 -0800, Junio C Hamano wrote:
> I am however not quite sure what conclusion you are trying to drive
> at by contrasting approaches #2 and #3.  The perceived problem of
> approach #2, if I am reading you correctly, is that the merge is
> what you vouch for but the commits on the side branch are not signed
> so there is no way for you (as the merge creator) to point fingers
> to when the result of the merge turns out to be problematic.  The
> argument for approach #3 would be that it would give you (as the
> merge creator) somebody to point fingers to if you forced others who
> ask you to pull from them to sign their commits.

I had to take another look at the article to see if my opinions have
since changed.

My argument for Option #3 (signing each commit) was that it explicitly
denotes that a particular commit was reviewed; signing a merge commit
states that implicitly.

I personally sign any commit on master; usually, this is a merge
commit.  But this is because I have a high level of confidence in the
integrity of my system, my ability to notice commits that are not likely
to be my own, and because the auditing requirements of my software are,
well, non-existent.

My wife was recently watching Elf (the movie), which had an interesting
example, so I'll make use of it:  One of the characters works for a
publishing company.  A children's book was printed, but was missing
content on the last two pages.  The character was responsible for
signing off on the book.  His boss stormed in, and the character used
the excuse that something must have gone wrong during printing; but his
boss pulled out the proofs that went to press---each page had the
character's initials, including the blank ones.

Signing each commit is like initialing each page.  Of course, these
scenarios are drastically different---a page of a book is its own
finished result, whereas a commit is more likely to be a single
component of a larger feature.  But adapt it how you will.

Another possibility is that a malicious commit could be hidden within a
changeset by introducing another commit that later reverts the change;
there would be nothing in the diff between `topic' and `HEAD', but an
operation like `bisect' could check out the commit and run malicious
code.  So the question is then: does the signing of the merge commit
indicate review of the diff, or review of each commit?

If the review of each commit doesn't matter, does the history matter?
In which case, is squashing the better option?

> Does it absolve you from blame if you can say with certainty (thanks
> to GPG keys on them) that those commits on the side branch that adds
> unwanted (from 'maint' policy's point of view) new feature were made
> by somebody else, because the project used the approach #3?
>
> Not really.

You might be thinking that I'm suggesting that the merge commit carry a
different signature than the commits on the side branch.  That's
certainly an option, but wasn't what I was referring to, since the
GPG-signature of the author doesn't indicate that the code was reviewed
by the person responsible for doing so.  And no additional review data
(e.g. a Signed-off-by) can be added to the commit object without
invalidating the signature of the author (except by notes, or a similar
concept).  So in this case, if you truly do want to maintain the
signature of the author (I would!), you must sign the merge commit and
indicate the review of each commit in some other manner, or rely on the
implicit assumption that each commit has been reviewed.

And that may not be a problem.

Instead, Option #3 was stating that the person responsible for merging
would also be responsible for signing each individual commit, as a means
of stating "yep, this was reviewed".

> When you sign your merge with "merge -S", you are vouching for the
> contents of the whole tree, not just "I made this merge, but I don't
> have anything to do with what it pulled in."  It does not really
> matter to the end users where the changes came from.  You are
> certifying that "git diff HEAD^ HEAD" after making the merge is what
> you are pleased with by signing the merge.

And `git diff HEAD^ HEAD' may show nothing wrong, as I mentioned
above.  But otherwise, yes, you're correct.  The goal would not be to
absolve blame in this scenario.  The only goal of signing each commit
would be to provide confidence to those who may care about the depth of
the review process.

Rather, it is the _absence_ of a GPG-signed merge that would be the
problem, since you can't assert your identity in that case.  If you have
GPG-signed the merge, then you've avoided the problems in the "horror
story" part of the article, but you've introduced a whole new set of
them if you introduced bad changes, since you now can't deny it. ;)

> But ultimately, the responsibility lies on the person who creates
> the topmost merge and advances the tip of the history the users of
> the end product of the project considers the authoritative one.

Indeed.

I would like to take some time to catch up on all the changes that have
been made since I wrote that article, and look through the mailing list
to see your philosophy and others' regarding Git's signing
features.  The thought experiment that prompted my article was
considering what may happen if a coworker decided to commit as me, and
do so maliciously (ironically, we still don't sign commits at work, but
it'll be coming).  This would be an inside job---that coworker would
have access to the repository, and the only way I could assert my
identity is cryptographically or through server logs, the latter of
which could still be modified with root access.  By introducing signed
pushes, Git has actually solved that problem in a less invasive way that
is practical for internal use (though less so for a larger community
wanting to observe repository integrity on their own, but that's not
what it's for).

- -- 
Mike Gerwitz
Free Software Hacker | GNU Maintainer
http://mikegerwitz.com
FSF Member #5804 | GPG Key ID: 0x8EE30EAB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJUgpg5AAoJEPIruBWO4w6rZ6IQALRiJOUeYNIJGVdbpJ9uynda
p7HuWkJyF6lSSyk8hPFCrGKde5YmwD6tsW9xxnwSCIw8qRvMPPRxDFH4P8KzzWMm
jwe/QWVRiobJ1uViSawpvfrrrK1ZnrScIGW9MuJtuURuZtazvf913OOwZKIm5Qnm
NWy3Xv9P1wqhOYnYSKUd6LbJFTT8MH6bG9U13rkZ7YXUDIygAAjCNAZmfmTJ+hv2
KUwYlHSQd0VtbI09cB9+oUVRFwK3Bmek6TgVb7MJlCNSKn2y+8EZWE9MYdKKl2tN
opgqTUjTIaqn50JtspvKYJpMkOA17+MtHXUG5Q0gMZjw69mueXl+MaSJSr8YDkSb
AAAsr0NYscK7iwDs8xCZCV6aROirL0XtuGazvFQ6Fma5bvl0xtVEowPsJK4Qb17c
mvn0Z8wKUQvMcM71iNQGg/uBJvFfmJG6PYujFJ1pOnt2b3w5b53sgL3Dq5Eo54Za
IJY7cqZOSWyKzkYWO3uL+FdkPq79BIQFalVBooaEyC8lno3BQH+zb45czYDhB/gr
D8eLnCDQTq/or118jYWmZw+UFXvYvwu6S5g4p9pVpTRKvnvA/VbDoNINeMRhVSdY
tw3pEhvp06IVQeoJwXAffvtBdC32ohcQCPHkMh8WQAHqbBw9FjKiA8Yk7ordrDyU
a73dxZuXMt1VxTBeLyjy
=ui4w
-----END PGP SIGNATURE-----