gpg verify git sub modules useful?
When using git submodules, is there value in iterating about the git submodules running "git verfiy-commit HEAD" or would that be already covered by the git submodule verification? Cheers, Patrick
Re: gpg verify git sub modules useful?
Good questions, thank you for trying to figure out what I am asking. :) Junio C Hamano: > Patrick Schleizer writes: > >> When using git submodules, is there value in iterating about the git >> submodules running "git verfiy-commit HEAD" or would that be already >> covered by the git submodule verification? > > That depends on what you are referring to with the "git submodule > verification" cd submodule if ! git verfiy-commit HEAD ; then error fi > and more importantly what threat you are guarding > against. All main (non-submodule) (merge) commits and submodule (merge) commits are signed by me. 1) git --recursive clone main (non-submodule) git repository 2) cd git main repository 3) git verify-commit HEAD or git verify-tag tag-name 4) git submodule update What if the main (non-submodule) git repository gpg signature was okay but then after git fetched the submodules these compromised (MITM'ed) ones? Does the having gpg verified the root (main git repository) ensure that submodule commits are also quasi verified? > "git -C verify-commit HEAD" may make sure > that the contents of that commit object is GPG signed by whoever you > trust--is that what you want to make sure? > Or do you want all > commits in the submodule history to be similarly signed because the > tree of the superproject can switch to some other commit there? I guess so.
How safe are signed git tags? Only as safe as SHA-1 or somehow safer?
Hi! How safe are signed git tags? Especially because git uses SHA-1. There is contradictory information around. So if one verifies a git tag (`git tag -v tagname`), then `checksout`s the tag, and checks that `git status` reports no untracked/modified files, without further manually auditing the code, how secure is this actually? Is it only as safe as SHA-1? Let's assume an adversary, that is capable of producing SHA-1 collisions. Linus Torvalds said: [1] > Git uses SHA-1 not for security And goes on. > The security parts are elsewhere Could you please elaborate on this? Where are the security parts? Can you please briefly explain how these work? Where can I read more about this? Wikipedia says. [2] > Nonetheless, without second preimage resistance [3] of SHA-1 signed commits and tags would no longer secure the state of the repository as they only sign the root of a Merkle tree [4]. Which contradicts what Linus Torvalds said. What does that mean for security? Which statement is true? > "The source control management system Git uses SHA-1 not for security but for ensuring that the data has not changed due to accidental corruption. Linus Torvalds has said, "If you have disk corruption, if you have DRAM corruption, if you have any kind of problems at all, Git will notice them. It's not a question of if, it's a guarantee. You can have people who try to be malicious. They won't succeed. [...] Nobody has been able to break SHA-1, but the point is the SHA-1, as far as Git is concerned, isn't even a security feature. It's purely a consistency check. The security parts are elsewhere, so a lot of people assume that since Git uses SHA-1 and SHA-1 is used for cryptographically secure stuff, they think that, OK, it's a huge security feature. It has nothing at all to do with security, it's just the best hash you can get. [...] I guarantee you, if you put your data in Git, you can trust the fact that five years later, after it was converted from your hard disk to DVD to whatever new technology and you copied it along, five years later you can verify that the data you get back out is the exact same data you put in. [...] One of the reasons I care is for the kernel, we had a break in on one of the BitKeeper sites where people tried to corrupt the kernel source code repositories." [6] If (!) I understand Mike Gerwitz ([...] GNU [...]) 's opinion, his opinion is, that for best security each and every commit should be signed for best possible git verification security. See also: - Mike Gerwitz's "A Git Horror Story: Repository Integrity With Signed Commits" [7] - Verbose reply by Mike Gerwitz to my question. [8] - Similar question on security stackexchange. [9] Quote: "Nevertheless, If somebody managed to find a way how to find SHA1 collisions easily, then git would have much bigger problem." Cheers, Patrick [1] https://www.youtube.com/watch?v=4XpnKHJAok8&t=56m20s [2] https://en.wikipedia.org/wiki/SHA-1#Data_integrity [3] https://en.wikipedia.org/wiki/Second_preimage_resistance [4] https://en.wikipedia.org/wiki/Merkle_tree [5] https://www.youtube.com/watch?v=4XpnKHJAok8&t=56m20s [6] https://en.wikipedia.org/wiki/SHA-1#Data_integrity [7] http://mikegerwitz.com/papers/git-horror-story [8] https://www.whonix.org/forum/index.php/topic,538.msg4278.html#msg4278 [9] https://security.stackexchange.com/questions/67920/how-safe-are-signed-git-tags-only-as-safe-as-sha-1-or-somehow-safer -- 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: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?
Dear git developers! Jeff King wrote: > On Sun, Nov 16, 2014 at 03:31:10PM +0000, Patrick Schleizer wrote: > >> How safe are signed git tags? Especially because git uses SHA-1. There >> is contradictory information around. >> >> So if one verifies a git tag (`git tag -v tagname`), then `checksout`s >> the tag, and checks that `git status` reports no untracked/modified >> files, without further manually auditing the code, how secure is this >> actually? Is it only as safe as SHA-1? > > Yes, it is only as "safe as SHA-1" in the sense that you have GPG-signed > only a SHA-1 hash. If somebody can find a collision with a hash you have > signed, they can substitute the colliding data for the data you signed. > > Of course, "safe as SHA-1" and "find a collision" are vague. If > pre-image attacks are feasible (i.e., given already-published SHA-1, I > can find a different input with the same SHA-1), then attacks are > trivial. But when people talk about attacks on SHA-1, they are usually > referring to finding a collision between two new pieces of data. You can > also use that in an attack, but it's much less straightforward > (basically, you need to get somebody to sign one of the colliding pieces > of data and then replace it with the other). Sounds pretty sad. Isn't this a security issue that should be fixed? Rather than discussing how feasible collisions in SHA-1 are... Attacks on SHA-1 are only getting worse, no? Since the Snowden revelations we know that powerful adversaries that are working on such things and would use such weaknesses to exploit users. Dear git developers, could you please make a long story short? Change to some stronger hash algorithm? (sha256, sha512, or so?) Or provide an option for that? > And of course there is the question of getting the colliding data to the > victim. Git does collision checks whenever a remote (e.g., from a "git > fetch") gives us data that we already have. So you could poison new > cloners with bad data, but you could not convince a repository with the > existing "good" half of the collision to fetch the "evil" half. Poison git cloners with bad data is exactly my point here. Because sometimes I am a cloner of my own code - cloning it on a separate machine - then verify it using gpg - but don't check it any further. In such cases, I'd prefer if security wouldn't depend on SHA-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
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) " 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 " 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 " 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: [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
