4 ms·

I don't know how github works but I would hope that there are users-based restrictions. "you have to basically trust Github" And that's why entrusting a third

I don't know how github works but I would hope that there are users-based restrictions. "you have to basically trust Github" And that's why entrusting a third party with managing something as critical as your source code is unwise.

wongarsu 8y ago
>And that's why entrusting a third party with managing something as critical as your source code is unwise. Yes, but signing your code strongly reduces the need for trust. If every commit is signed, and every checkout and clone checks that commits are signed by one of the trusted parties, Github has no chance to insert or modify code.
- Leace 8y ago
  > (...) Github has no chance to insert or modify code. Yes, exactly! The only slim window is refs. All-signed-commits still does not protect against someone pushing signed commit from branch "testing" to branch "master". But `git push --signed` [0] makes it possible to have an audit log of all ref modifications. [0]: https://github.com/git/git/commit/a85b377d0419a9dfaca8af2320cc33b051cbed04 https://github.com/git/git/commit/a85b377d0419a9dfaca8af2320...
- ElBarto 8y ago
  If you do not trust Github then signed commits will not help since Github physically controls the repository.
  - patmorgan23 8y ago
    Github can't fake the sigs
    - ElBarto 8y ago
      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.
  - deleted 8y ago
    [deleted]
hrktb 8y ago
At the size of Mozilla I wonder what would be the threshold for them to decide to commit to basically move to their own github like interface to manage all of that. I assume even maintaining a private gitlab would have a non trivial cost and need dedicated OPS as well at their size.
- cjbprime 8y ago
  They already do that for their main codebases; as the article says, this is just about their use of GitHub for other projects.
- jvehent 8y ago
  It's not just a matter of operational cost. We spend a lot of time and effort making our code accessible to new contributors, and lowering that barrier is very important. Contributing to code in Mercurial is hard (but getting easier with Phabricator), whereas code in GitHub is easily accessible. There is also the question of integrating with external services. GitHub has a very mature ecosystem that's helpful to developers and lets us ship better products faster.
  - ElBarto 8y ago
    Considering how sensitive piece of software browsers are these days, I would think that security should be the priority.

wongarsu 8y ago

>And that's why entrusting a third party with managing something as critical as your source code is unwise. Yes, but signing your code strongly reduces the need for trust. If every commit is signed, and every checkout and clone checks that commits are signed by one of the trusted parties, Github has no chance to insert or modify code.

Leace 8y ago
> (...) Github has no chance to insert or modify code. Yes, exactly! The only slim window is refs. All-signed-commits still does not protect against someone pushing signed commit from branch "testing" to branch "master". But `git push --signed` [0] makes it possible to have an audit log of all ref modifications. [0]: https://github.com/git/git/commit/a85b377d0419a9dfaca8af2320cc33b051cbed04 https://github.com/git/git/commit/a85b377d0419a9dfaca8af2320...
ElBarto 8y ago
If you do not trust Github then signed commits will not help since Github physically controls the repository.
- patmorgan23 8y ago
  Github can't fake the sigs
  - ElBarto 8y ago
    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.
- deleted 8y ago
  [deleted]

hrktb 8y ago

At the size of Mozilla I wonder what would be the threshold for them to decide to commit to basically move to their own github like interface to manage all of that. I assume even maintaining a private gitlab would have a non trivial cost and need dedicated OPS as well at their size.

cjbprime 8y ago
They already do that for their main codebases; as the article says, this is just about their use of GitHub for other projects.
jvehent 8y ago
It's not just a matter of operational cost. We spend a lot of time and effort making our code accessible to new contributors, and lowering that barrier is very important. Contributing to code in Mercurial is hard (but getting easier with Phabricator), whereas code in GitHub is easily accessible. There is also the question of integrating with external services. GitHub has a very mature ecosystem that's helpful to developers and lets us ship better products faster.
- ElBarto 8y ago
  Considering how sensitive piece of software browsers are these days, I would think that security should be the priority.