Re: git log --pretty=format:%H$t%aN$t%s$t%G? --show-signature
-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
git log --pretty=format:%H$t%aN$t%s$t%G? --show-signature
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 GerwitzYet 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) m...@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 GerwitzModified barG - 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 adrela...@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 adrela...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git log --pretty=format:%H$t%aN$t%s$t%G? --show-signature
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey Patrick, On Thu, Dec 04, 2014 at 17:21:06 +, 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- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Whonix-devel] git log --pretty=format:%H$t%aN$t%s$t%G? --show-signature
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git log --pretty=format:%H$t%aN$t%s$t%G? --show-signature
Mike Gerwitz mikegerw...@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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
