{"thread":{"id":"38110","subject":"git log --pretty=\"format:%H$t%aN$t%s$t%G?\" --show-signature","startedAt":"2014-12-04T17:21:06Z","lastAt":"2014-12-06T05:46:32Z","messageCount":5,"participants":["Patrick Schleizer","Mike Gerwitz","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"253063","messageId":"54809802.6030609@whonix.org","threadId":"38110","inReplyTo":null,"subject":"git log --pretty=\"format:%H$t%aN$t%s$t%G?\" --show-signature","fromName":"Patrick Schleizer","fromEmail":"patrick-mailinglists@whonix.org","sentAt":"2014-12-04T17:21:06Z","receivedAt":"2014-12-04T17:21:06Z","isPatch":false,"sender":{"key":"patrick-mailinglists@whonix.org","avatar":null},"body":"Dear git mailing list,\nDear Mike Gerwitz,\n\naccording to http://mikegerwitz.com/papers/git-horror-story#script-trust\nthe output of:\n\ngit log --pretty=\"format:%H$t%aN$t%s$t%G?\" --show-signature\n\nshould look like this:\n\n-----\n\nf72924356896ab95a542c495b796555d016cbddd       Mike Gerwitz    Yet\nanother foo\ngpg: Signature made Sun 22 Apr 2012 01:37:26 PM EDT using RSA key ID\n8EE30EAB\ngpg: Good signature from \"Mike Gerwitz (Free Software Developer)\n<mike@mikegerwitz.com>\"\ngpg: WARNING: This key is not certified with a trusted signature!\ngpg:          There is no indication that the signature belongs to the\nowner.\nPrimary key fingerprint: 2217 5B02 E626 BC98 D7C0  C2E5 F22B B815 8EE3 0EAB\nafb1e7373ae5e7dae3caab2c64cbb18db3d96fba       Mike Gerwitz    Modified\nbar    G\n\n-----\n\nBut when I run that command, spaces are missing. (Using a user that does\nnot know my gpg public key for testing purposes.) See output:\n\n-----\n\nuser2@host:/home/user/testrepo$ git log\n--pretty=\"format:%H$t%aN$t%s$t%G?\" --show-signature\ngpg: Signature made Thu 04 Dec 2014 04:37:58 PM UTC using RSA key ID\n77BB3C48\ngpg: Good signature from \"Patrick Schleizer <adrelanos@riseup.net>\"\ngpg: WARNING: This key is not certified with a trusted signature!\ngpg:          There is no indication that the signature belongs to the\nowner.\nPrimary key fingerprint: 916B 8D99 C38E AF5E 8ADC  7A2A 8D66 066A 2EEA CCDA\n     Subkey fingerprint: 6E97 9B28 A6F3 7C43 BE30  AFA1 CB8D 50BB 77BB 3C48\n529bbc076f05c13023580ea7be7ba63aba3e9672Patrick Schleizersigned commit 2U\ngpg: Signature made Thu 04 Dec 2014 04:29:32 PM UTC using RSA key ID\n77BB3C48\ngpg: Good signature from \"Patrick Schleizer <adrelanos@riseup.net>\"\ngpg: WARNING: This key is not certified with a trusted signature!\ngpg:          There is no indication that the signature belongs to the\nowner.\nPrimary key fingerprint: 916B 8D99 C38E AF5E 8ADC  7A2A 8D66 066A 2EEA CCDA\n     Subkey fingerprint: 6E97 9B28 A6F3 7C43 BE30  AFA1 CB8D 50BB 77BB 3C48\nea1615ac1a9fe9f957f91f54a33a60d57828a32fPatrick Schleizersigned commitU\n75e79a211963907afd3a6d2f28c3571d37140231Patrick Schleizerreal long\ncommit msg Please enter the commit message for your changes. Lines\nstarting with '#' will be ignored, and an empt\n30096d1633ef22463c1a770288755ae5325f1242Patrick Schleizer2N\ne7be12378d2805bebe531bd01cbec9dec1f79032Patrick Schleizerinitial commitN\n(END)\n\n-----\n\nAny idea? Am I doing something wrong?\n\nI am asking, because therefore Mike Gerwitz's Quote \"Signature Check\nScript With Web Of Trust\" verification script (\nhttp://mikegerwitz.com/papers/git-horror-story#script-trust ) does not\nwork for me.\n\nMike, could you please put your various git commit verification helper\nscripts into a publicly visible?\n\nBy the way, any chance that these useful helper scripts could make their\nway into the official distribution of git as a stopgap until native git\ncommit verification support gets improved?\n\nCheers,\nPatrick\n"},{"id":"253068","messageId":"871tofuw7h.fsf@gnu.org","threadId":"38110","inReplyTo":"54809802.6030609@whonix.org","subject":"Re: git log --pretty=\"format:%H$t%aN$t%s$t%G?\" --show-signature","fromName":"Mike Gerwitz","fromEmail":"mikegerwitz@gnu.org","sentAt":"2014-12-04T18:05:38Z","receivedAt":"2014-12-04T18:05:38Z","isPatch":false,"sender":{"key":"mikegerwitz@gnu.org","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nHey Patrick,\n\nOn Thu, Dec 04, 2014 at 17:21:06 +0000, Patrick Schleizer wrote:\n> git log --pretty=\"format:%H$t%aN$t%s$t%G?\" --show-signature\n> [...]\n> But when I run that command, spaces are missing. (Using a user that does\n> not know my gpg public key for testing purposes.) See output:\n>\n> -----\n>\n> user2@host:/home/user/testrepo$ git log\n> --pretty=\"format:%H$t%aN$t%s$t%G?\" --show-signature\n\nThat is because the variable `$t' is defined in my script on the\npreceding line, as a tab character.  You can insert it directly using\nC-V <TAB>, or $'\\t' in bash.\n\n> Mike, could you please put your various git commit verification helper\n> scripts into a publicly visible?\n\nYou can use this:\n\n  https://gitorious.org/easejs/easejs/source/ee85b058df783ffaa9f8d5ae58f9eb6d7586b0ca:tools/signchk\n\nBut note that the default value of the `chkafter' var is\nease.js-specific.\n\n> By the way, any chance that these useful helper scripts could make their\n> way into the official distribution of git as a stopgap until native git\n> commit verification support gets improved?\n\nIt has since improved; I'm looking for the time to update the article,\nor write a follow-up.\n\nGit has since added other pretty formatting options as well:\n\n  https://github.com/git/git/blob/master/Documentation/pretty-formats.txt#L140\n\nGit v2.1.0 also added a `verify-commit' command:\n\n  https://github.com/git/git/blob/master/Documentation/git-verify-commit.txt\n\nI haven't used it yet.\n\nHope that helps.\n\n- -- \nMike Gerwitz\nFree Software Hacker | GNU Maintainer\nhttp://mikegerwitz.com\nFSF Member #5804 | GPG Key ID: 0x8EE30EAB\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.11 (GNU/Linux)\n\niQIcBAEBAgAGBQJUgKJyAAoJEPIruBWO4w6rdS8QAMEtQhklDe4zXju0uc6ksqYl\naXdXhE7HcyUDl6yWXEheXH4oCRLSthS+8MPQfuY8gae1eRvyHx3rViGpMEyB8s5B\nxhAQpOLVmro0QIwIZ/HGX4IKoGVq/QyqvLNR8iqnV8GXPu+ckGIG/UvrkFFSaLW8\neFUvQLbNITViVgQljCzzfptL9dQvdra0D1EXxRk8+h8Sw4vKRN54h0tqKVw5PcsT\n4sFUBVwgmzILNKydFkMu1C+pDwnemhS04PtcrpmUTniOzLPhWJiZwzgDV5j9tOPq\n7noLrnw0kpm6PbX90i2+uSVGmh6zgoR69h7SAZGJEiHQj4BiZetLMwxJL25o73/c\n1/9tWT/7kAcpvzAjPjRMS3BqV7AVwNqTKKblCszfunS87aWLs1t/bgUg4e6x3lTJ\nJxyxkKnSnn3dzntMfB9UuuJ6bdtn1pJci4Ptvl2yzKHaZv7ImV78UIuxdthtMgMn\neBawq3wm7HBMETkDDyRSpuPOEycBSnWZL2dL4Xc9IxPKDTJUvHTRUXxy4v2Juiv9\nPogao25j6EpTlOqx29Y9Y95ITw/UdQU7NjPAGFNxIZZTgjzHrcIlaEKuoHp+t6oh\ns8OPhD+FMNWBFdAda+zP785sUbyF93/2xBK/HFyTUinOLn1/BJBC0FqHfeYd1hQe\ncJ0rYnOtckycQv+re9hz\n=+Rub\n-----END PGP SIGNATURE-----\n"},{"id":"253092","messageId":"5480C417.4050805@riseup.net","threadId":"38110","inReplyTo":"871tofuw7h.fsf@gnu.org","subject":"Re: [Whonix-devel] git log --pretty=\"format:%H$t%aN$t%s$t%G?\" --show-signature","fromName":"Patrick Schleizer","fromEmail":"adrelanos@riseup.net","sentAt":"2014-12-04T20:29:11Z","receivedAt":"2014-12-04T20:29:11Z","isPatch":false,"sender":{"key":"adrelanos@riseup.net","avatar":null},"body":"Thanks Mike!\n\nMike Gerwitz wrote:\n>> Mike, could you please put your various git commit verification helper\n>> scripts into a publicly visible?\n>\n> You can use this:\n>\n>\nhttps://gitorious.org/easejs/easejs/source/ee85b058df783ffaa9f8d5ae58f9eb6d7586b0ca:tools/signchk\n>\n> But note that the default value of the `chkafter' var is\n> ease.js-specific.\n\nDo you have script somewhere in public git that also checks the web of\ntrust?\n\nFor your blog post it would be nice to have a ease.js unspecific one.\n\nOtherwise I just wait for our updated blog post and/or for my distro to\nupgrade to git 2.1.\n\nCheers,\nPatrick\n"},{"id":"253096","messageId":"xmqqk327ruh8.fsf@gitster.dls.corp.google.com","threadId":"38110","inReplyTo":"871tofuw7h.fsf@gnu.org","subject":"Re: git log --pretty=\"format:%H$t%aN$t%s$t%G?\" --show-signature","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-12-04T21:11:15Z","receivedAt":"2014-12-04T21:11:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mike Gerwitz <mikegerwitz@gnu.org> writes:\n\n> It has since improved; I'm looking for the time to update the article,\n> or write a follow-up.\n\nThanks for an amusing read.  We also let you merge a signed tag\nthese days, so that in a variant of your merge scenario #2, your\nmerge commit can carry your GPG signature, made when you do the \"git\nmerge -S $other_history\" to merge $other_history you obtained from\nyour trusted colleague, as well as the signed tag your trusted\ncolleague made with her GPG signature.  That way, upon seeing that\nmerge, a third-party can verify that the merge was made by you, and\nalso the history of the side branch integrated to your history with\nthat merge is vouched by your trustred colleague.\n\nI am however not quite sure what conclusion you are trying to drive\nat by contrasting approaches #2 and #3.  The perceived problem of\napproach #2, if I am reading you correctly, is that the merge is\nwhat you vouch for but the commits on the side branch are not signed\nso there is no way for you (as the merge creator) to point fingers\nto when the result of the merge turns out to be problematic.  The\nargument for approach #3 would be that it would give you (as the\nmerge creator) somebody to point fingers to if you forced others who\nask you to pull from them to sign their commits.\n\nBut I am not sure if that is the right way to look at the bigger\npicture.\n\nImagine you are working on a project with two branches, maint and\nmaster.  The policy adopted by the project is to use the maint\nbranch to prepare for the next maintenance release, which should\nnever add new features.  New features are to be merged to master\nfor the next feature release.\n\nAnd imagine that you made a mistake of merging somebody else's\nbranch that adds a new feature, which happens to be perfectly done\nand introduces no bug, to the maint branch.  Your merge is signed by\nyour GPG key.\n\nDoes it absolve you from blame if you can say with certainty (thanks\nto GPG keys on them) that those commits on the side branch that adds\nunwanted (from 'maint' policy's point of view) new feature were made\nby somebody else, because the project used the approach #3?\n\nNot really.\n\nHow would that case be any different from the case where the side\nbranch you merged were buggy or even malicious?  After all, your GPG\nsignature carries more weight than \"Yes, I did this random merge but\nI did so without thinking about what damage it causes to the history\nby pulling in other peoples' changes\".  Or at least it should carry\nmore weight to your users who trust a history having your GPG\nsignature.  \"This history is coming from Mike whom we trust\" is what\nyour users expect, no?  When you sign your merge with \"merge -S\",\nyou are vouching for the contents of the whole tree, not just \"I\nmade this merge, but I don't have anything to do with what it pulled\nin.\"  It does not really matter to the end users where the changes\ncame from.  You are certifying that \"git diff HEAD^ HEAD\" after\nmaking the merge is what you are pleased with by signing the merge.\n\nHaving said that, what approach #3 (or merging a signed tag) does\ngive you as the merge creator is a distrubution of trust.  You may\nnot have to be _so_ careful verifying \"git diff HEAD^ HEAD\" of the\nmerge when you know you can trust the side branch you are merging\ninto your history was done by somebody you trust.\n\nBut ultimately, the responsibility lies on the person who creates\nthe topmost merge and advances the tip of the history the users of\nthe end product of the project considers the authoritative one.\n"},{"id":"253233","messageId":"87wq65z5xj.fsf@gnu.org","threadId":"38110","inReplyTo":"xmqqk327ruh8.fsf@gitster.dls.corp.google.com","subject":"Re: git log --pretty=\"format:%H$t%aN$t%s$t%G?\" --show-signature","fromName":"Mike Gerwitz","fromEmail":"mikegerwitz@gnu.org","sentAt":"2014-12-06T05:46:32Z","receivedAt":"2014-12-06T05:46:32Z","isPatch":false,"sender":{"key":"mikegerwitz@gnu.org","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nThanks for the input, Junio.\n\nOn Thu, Dec 04, 2014 at 13:11:15 -0800, Junio C Hamano wrote:\n> I am however not quite sure what conclusion you are trying to drive\n> at by contrasting approaches #2 and #3.  The perceived problem of\n> approach #2, if I am reading you correctly, is that the merge is\n> what you vouch for but the commits on the side branch are not signed\n> so there is no way for you (as the merge creator) to point fingers\n> to when the result of the merge turns out to be problematic.  The\n> argument for approach #3 would be that it would give you (as the\n> merge creator) somebody to point fingers to if you forced others who\n> ask you to pull from them to sign their commits.\n\nI had to take another look at the article to see if my opinions have\nsince changed.\n\nMy argument for Option #3 (signing each commit) was that it explicitly\ndenotes that a particular commit was reviewed; signing a merge commit\nstates that implicitly.\n\nI personally sign any commit on master; usually, this is a merge\ncommit.  But this is because I have a high level of confidence in the\nintegrity of my system, my ability to notice commits that are not likely\nto be my own, and because the auditing requirements of my software are,\nwell, non-existent.\n\nMy wife was recently watching Elf (the movie), which had an interesting\nexample, so I'll make use of it:  One of the characters works for a\npublishing company.  A children's book was printed, but was missing\ncontent on the last two pages.  The character was responsible for\nsigning off on the book.  His boss stormed in, and the character used\nthe excuse that something must have gone wrong during printing; but his\nboss pulled out the proofs that went to press---each page had the\ncharacter's initials, including the blank ones.\n\nSigning each commit is like initialing each page.  Of course, these\nscenarios are drastically different---a page of a book is its own\nfinished result, whereas a commit is more likely to be a single\ncomponent of a larger feature.  But adapt it how you will.\n\nAnother possibility is that a malicious commit could be hidden within a\nchangeset by introducing another commit that later reverts the change;\nthere would be nothing in the diff between `topic' and `HEAD', but an\noperation like `bisect' could check out the commit and run malicious\ncode.  So the question is then: does the signing of the merge commit\nindicate review of the diff, or review of each commit?\n\nIf the review of each commit doesn't matter, does the history matter?\nIn which case, is squashing the better option?\n\n> Does it absolve you from blame if you can say with certainty (thanks\n> to GPG keys on them) that those commits on the side branch that adds\n> unwanted (from 'maint' policy's point of view) new feature were made\n> by somebody else, because the project used the approach #3?\n>\n> Not really.\n\nYou might be thinking that I'm suggesting that the merge commit carry a\ndifferent signature than the commits on the side branch.  That's\ncertainly an option, but wasn't what I was referring to, since the\nGPG-signature of the author doesn't indicate that the code was reviewed\nby the person responsible for doing so.  And no additional review data\n(e.g. a Signed-off-by) can be added to the commit object without\ninvalidating the signature of the author (except by notes, or a similar\nconcept).  So in this case, if you truly do want to maintain the\nsignature of the author (I would!), you must sign the merge commit and\nindicate the review of each commit in some other manner, or rely on the\nimplicit assumption that each commit has been reviewed.\n\nAnd that may not be a problem.\n\nInstead, Option #3 was stating that the person responsible for merging\nwould also be responsible for signing each individual commit, as a means\nof stating \"yep, this was reviewed\".\n\n> When you sign your merge with \"merge -S\", you are vouching for the\n> contents of the whole tree, not just \"I made this merge, but I don't\n> have anything to do with what it pulled in.\"  It does not really\n> matter to the end users where the changes came from.  You are\n> certifying that \"git diff HEAD^ HEAD\" after making the merge is what\n> you are pleased with by signing the merge.\n\nAnd `git diff HEAD^ HEAD' may show nothing wrong, as I mentioned\nabove.  But otherwise, yes, you're correct.  The goal would not be to\nabsolve blame in this scenario.  The only goal of signing each commit\nwould be to provide confidence to those who may care about the depth of\nthe review process.\n\nRather, it is the _absence_ of a GPG-signed merge that would be the\nproblem, since you can't assert your identity in that case.  If you have\nGPG-signed the merge, then you've avoided the problems in the \"horror\nstory\" part of the article, but you've introduced a whole new set of\nthem if you introduced bad changes, since you now can't deny it. ;)\n\n> But ultimately, the responsibility lies on the person who creates\n> the topmost merge and advances the tip of the history the users of\n> the end product of the project considers the authoritative one.\n\nIndeed.\n\nI would like to take some time to catch up on all the changes that have\nbeen made since I wrote that article, and look through the mailing list\nto see your philosophy and others' regarding Git's signing\nfeatures.  The thought experiment that prompted my article was\nconsidering what may happen if a coworker decided to commit as me, and\ndo so maliciously (ironically, we still don't sign commits at work, but\nit'll be coming).  This would be an inside job---that coworker would\nhave access to the repository, and the only way I could assert my\nidentity is cryptographically or through server logs, the latter of\nwhich could still be modified with root access.  By introducing signed\npushes, Git has actually solved that problem in a less invasive way that\nis practical for internal use (though less so for a larger community\nwanting to observe repository integrity on their own, but that's not\nwhat it's for).\n\n- -- \nMike Gerwitz\nFree Software Hacker | GNU Maintainer\nhttp://mikegerwitz.com\nFSF Member #5804 | GPG Key ID: 0x8EE30EAB\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.11 (GNU/Linux)\n\niQIcBAEBAgAGBQJUgpg5AAoJEPIruBWO4w6rZ6IQALRiJOUeYNIJGVdbpJ9uynda\np7HuWkJyF6lSSyk8hPFCrGKde5YmwD6tsW9xxnwSCIw8qRvMPPRxDFH4P8KzzWMm\njwe/QWVRiobJ1uViSawpvfrrrK1ZnrScIGW9MuJtuURuZtazvf913OOwZKIm5Qnm\nNWy3Xv9P1wqhOYnYSKUd6LbJFTT8MH6bG9U13rkZ7YXUDIygAAjCNAZmfmTJ+hv2\nKUwYlHSQd0VtbI09cB9+oUVRFwK3Bmek6TgVb7MJlCNSKn2y+8EZWE9MYdKKl2tN\nopgqTUjTIaqn50JtspvKYJpMkOA17+MtHXUG5Q0gMZjw69mueXl+MaSJSr8YDkSb\nAAAsr0NYscK7iwDs8xCZCV6aROirL0XtuGazvFQ6Fma5bvl0xtVEowPsJK4Qb17c\nmvn0Z8wKUQvMcM71iNQGg/uBJvFfmJG6PYujFJ1pOnt2b3w5b53sgL3Dq5Eo54Za\nIJY7cqZOSWyKzkYWO3uL+FdkPq79BIQFalVBooaEyC8lno3BQH+zb45czYDhB/gr\nD8eLnCDQTq/or118jYWmZw+UFXvYvwu6S5g4p9pVpTRKvnvA/VbDoNINeMRhVSdY\ntw3pEhvp06IVQeoJwXAffvtBdC32ohcQCPHkMh8WQAHqbBw9FjKiA8Yk7ordrDyU\na73dxZuXMt1VxTBeLyjy\n=ui4w\n-----END PGP SIGNATURE-----\n"}]}