5 ms·

Sigs are not important if they hold the repository to start with. If the premise is "I don't trust Github" then the only option is not to use Github. And, in a

Sigs are not important if they hold the repository to start with. If the premise is "I don't trust Github" then the only option is not to use Github. And, in any case, sigs do not prevent malicious code changes.

simias 8y ago
I don't understand what you mean exactly. What attack vector are you considering? If I sign a commit and push it on github anybody else can pull it from github and if they have my key than can validate that it is indeed me who made it. The only thing GH can do is modify it and strip the signature, modify it and replace the signature with a "fake" one that may fool people who don't have my public key or simply drop my commit altogether if for instance it contains a security fix (but then they also have to drop all future commits referencing this one since the hashes won't match).
- ElBarto 8y ago
  You cannot guarantee the integrity of a repository that is controlled by a third party. You have to trust them.
  - danieldk 8y ago
    You can. Git's DAG is a Merkle tree. If we compare the hashes of the latest commit two git repositories and they are identical, then they have exactly the same history up to and including that commit [1]. If GitHub modified a commit, the hashes of all commits starting at that commit would change. This is why commit signing is important, it makes it impossible to change commits up to the signed commit, since it would change the hash of the signed commit and signature verification will fail. [1] Or you found a way to modify the repository that leads to a hash collision. Which is unlikely.
- ElBarto 8y ago
  @danieldk: "If we compare the hashes of the latest commit two git repositories" Which implies that you hold a copy of the repository, which is therefore the master copy, as opposed to trusting a third party to do that.
  - danieldk 8y ago
    Which implies that you hold a copy of the repository, which is therefore the master copy, as opposed to trusting a third party to do that. No, you do not need to hold a copy of the repository. You only need a known-good hash. Commit signing is a way to vouch that a hash is good. Similarly, when downloading a distribution ISO, you do not have to trust the mirror, you only need someone trusted (e.g. the distribution maintainer) to vouch the correct hash of an ISO. In both cases, you can hash the data that you retrieved and compare to a hash that is known to be good.
- ElBarto 8y ago
  @danieldk: "No, you do not need to hold a copy of the repository. You only need a known-good hash. Commit signing is a way to vouch that a hash is good." The overhead is such that you are better off holding the repo yourself a la linux kernel. Note also that SHA1 collisions are a practical attack these days: https://shattered.io/ https://shattered.io/ . So if you rely on SHA1 hashes you have no guarantee...
  - danieldk 8y ago
    HackerNews pro-tip: you can react to a comment during the cool-down period by clicking on the timestamp of the comment ;). Of course, don't abuse it, there is a reason why the cool-down is there.
  - simias 8y ago
    shattered is not (yet) a practical attack on git because of the way the data is represented before being hashed. Managing to get a SHA1 collision while simultaneously getting a valid git object and a meaningful commit (with, say, a backdoor inserted instead of pseudorandom garbage that will fail to compile) is still vastly too difficult to be practical, at least with publicly available knowledge. Regarding the overhead I don't know what you mean and you're really grasping at straws at this point, how is validating a GPG signature harder than validating that, say, a website is actually hosting the official repo of a project instead of a malicious fork? What if my self-hosted website gets hacked mitm'd or DNS highjacked? GPG can still be used to validate that my commits are valid in these situations. Actually I'm not even tied to github or anything else in this situation, any mirror can be used without fear as long as my keys are secured.
  - tialaramex 8y ago
    Collision attacks allow somebody (say Greg) to produce two documents A and A' that hash the same. So hash(A) = hash(A'), with the result that signatures over A can be attached to A' and they work. But this attack does NOT allow an adversary who sees some document B to produce a forgery B' such that hash(B) = hash(B') If you believe Greg is a bad guy, don't let Greg make signed commits to your system. Trusting Alice and Bob to make signed commits doesn't allow Greg to attack you with a collision, only trusting Greg would do that, so don't trust Greg.
danieldk 8y ago
Sigs are not important if they hold the repository to start with. Why not? Someone can clone the repository and verify using my public key that I signed a commit. If GitHub modifies the repository, the chain of hashes changes, and the signature would be incorrect. And, in any case, sigs do not prevent malicious code changes. That is true. But if every commit was signed using a known signature, then you know who injected the malicious code. For a third party to inject malicious code, they would have to compromise the one committer's machine and/or key, rather than GitHub or a specific GitHub account. Also, once the attack is detected, you know which commits are potentially bad, namely those signed using the compromised key.
kccqzy 8y ago
I don't trust my ISP (that much), yet I feel fine to use my ISP to access my bank. That's because TLS protects me from malicious modifications by a middle man whose job is just to pipe my data. Suppose I don't trust GitHub. What makes you think I can't use signatures properly so that I can still trust the code hosted on GitHub, safe from malicious modifications by GitHub whose job is just to host my code?

simias 8y ago

I don't understand what you mean exactly. What attack vector are you considering? If I sign a commit and push it on github anybody else can pull it from github and if they have my key than can validate that it is indeed me who made it. The only thing GH can do is modify it and strip the signature, modify it and replace the signature with a "fake" one that may fool people who don't have my public key or simply drop my commit altogether if for instance it contains a security fix (but then they also have to drop all future commits referencing this one since the hashes won't match).

ElBarto 8y ago
You cannot guarantee the integrity of a repository that is controlled by a third party. You have to trust them.
- danieldk 8y ago
  You can. Git's DAG is a Merkle tree. If we compare the hashes of the latest commit two git repositories and they are identical, then they have exactly the same history up to and including that commit [1]. If GitHub modified a commit, the hashes of all commits starting at that commit would change. This is why commit signing is important, it makes it impossible to change commits up to the signed commit, since it would change the hash of the signed commit and signature verification will fail. [1] Or you found a way to modify the repository that leads to a hash collision. Which is unlikely.
ElBarto 8y ago
@danieldk: "If we compare the hashes of the latest commit two git repositories" Which implies that you hold a copy of the repository, which is therefore the master copy, as opposed to trusting a third party to do that.
- danieldk 8y ago
  Which implies that you hold a copy of the repository, which is therefore the master copy, as opposed to trusting a third party to do that. No, you do not need to hold a copy of the repository. You only need a known-good hash. Commit signing is a way to vouch that a hash is good. Similarly, when downloading a distribution ISO, you do not have to trust the mirror, you only need someone trusted (e.g. the distribution maintainer) to vouch the correct hash of an ISO. In both cases, you can hash the data that you retrieved and compare to a hash that is known to be good.
ElBarto 8y ago
@danieldk: "No, you do not need to hold a copy of the repository. You only need a known-good hash. Commit signing is a way to vouch that a hash is good." The overhead is such that you are better off holding the repo yourself a la linux kernel. Note also that SHA1 collisions are a practical attack these days: https://shattered.io/ https://shattered.io/ . So if you rely on SHA1 hashes you have no guarantee...
- danieldk 8y ago
  HackerNews pro-tip: you can react to a comment during the cool-down period by clicking on the timestamp of the comment ;). Of course, don't abuse it, there is a reason why the cool-down is there.
- simias 8y ago
  shattered is not (yet) a practical attack on git because of the way the data is represented before being hashed. Managing to get a SHA1 collision while simultaneously getting a valid git object and a meaningful commit (with, say, a backdoor inserted instead of pseudorandom garbage that will fail to compile) is still vastly too difficult to be practical, at least with publicly available knowledge. Regarding the overhead I don't know what you mean and you're really grasping at straws at this point, how is validating a GPG signature harder than validating that, say, a website is actually hosting the official repo of a project instead of a malicious fork? What if my self-hosted website gets hacked mitm'd or DNS highjacked? GPG can still be used to validate that my commits are valid in these situations. Actually I'm not even tied to github or anything else in this situation, any mirror can be used without fear as long as my keys are secured.
- tialaramex 8y ago
  Collision attacks allow somebody (say Greg) to produce two documents A and A' that hash the same. So hash(A) = hash(A'), with the result that signatures over A can be attached to A' and they work. But this attack does NOT allow an adversary who sees some document B to produce a forgery B' such that hash(B) = hash(B') If you believe Greg is a bad guy, don't let Greg make signed commits to your system. Trusting Alice and Bob to make signed commits doesn't allow Greg to attack you with a collision, only trusting Greg would do that, so don't trust Greg.

danieldk 8y ago

Sigs are not important if they hold the repository to start with. Why not? Someone can clone the repository and verify using my public key that I signed a commit. If GitHub modifies the repository, the chain of hashes changes, and the signature would be incorrect. And, in any case, sigs do not prevent malicious code changes. That is true. But if every commit was signed using a known signature, then you know who injected the malicious code. For a third party to inject malicious code, they would have to compromise the one committer's machine and/or key, rather than GitHub or a specific GitHub account. Also, once the attack is detected, you know which commits are potentially bad, namely those signed using the compromised key.

kccqzy 8y ago

I don't trust my ISP (that much), yet I feel fine to use my ISP to access my bank. That's because TLS protects me from malicious modifications by a middle man whose job is just to pipe my data. Suppose I don't trust GitHub. What makes you think I can't use signatures properly so that I can still trust the code hosted on GitHub, safe from malicious modifications by GitHub whose job is just to host my code?