5 ms·

What is more, you can: 1. clone https://github.com/torvalds/linux https://github.com/torvalds/linux into https://github.com/<YOURNAME>/linux https://github.com

What is more, you can: 1. clone https://github.com/torvalds/linux https://github.com/torvalds/linux into https://github.com/<YOURNAME>/linux https://github.com/<YOURNAME>/linux. 2. push a fake "torvalds" commit into your repo. 3. check the SHA of the the commit that you made. 4. the commit will be visible at the original repo URL with your SHA (https://github.com/torvalds/linux/commit/<SHA> https://github.com/torvalds/linux/commit/<SHA>), with no indication whatsoever that this is coming from a different repo I have reported this problem to GitHub a while ago and they replied to me that this is a well known feature of the repo "network".

jimktrains2 7y ago
I've never really understood Torvalds' reason for not cryptographiclly signing commits. > Btw, there's a final reason, and probably the really real one. Signing each commit is totally stupid. It just means that you automate it, and you make the signature worth less. It also doesn't add any real value, since the way the git DAG-chain of SHA1's work, you only ever need _one_ signature to make all the commits reachable from that one be effectively covered by that one. So signing each commit is simply missing the point. http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...
- Aperocky 7y ago
  Oh, I've had that at one of the place I used to work at. The git commit tree is signed, and once a team member left no one can create branches any more because all of his commits are now insecure. Yeah that was fun.
- Roritharr 7y ago
  I guess he's of the school that it doesn't matter who commits the code, it needs to be checked anyway, for bugs or being malicious.
- utopian3 7y ago
  Unless I am missing something, his point seems to be different. He doesn’t seem to care about the non-repudiation of a user
- tux1968 7y ago
  Because each commit is in a cryptographically secure chain, when you sign a Git tag it vouches for the referenced commit and all the commits preceding it. This can be done at important moments such as each release.
  - jimktrains2 7y ago
    Sure, but in the case presented by great-grand-parent is a leaf commit with an unknown providence. At the very least I don't think it's "totally stupid", even if I know it's not a panacea for all ills.
- gus_massa 7y ago
  Cryptographically signing the commits makes rebasing impossible (or at least more difficult). In some cases the rebase is very clean, and none of the modified files had changed by other commits. I guess in this case, git can have a rule to keep a "link" to the old commit and accept the old signature as a signature of the new commit. In some cases there are trivial changes, like indentation because someone else added an `if` around the code you are modifying. Sometimes part of the problem has been fixed. Sometimes one of the functions you use has an additional parameter. Sometimes the code has been moved to another file. In this cases it is difficult to automatically detect if the new rebased commit is equal enough to the old commit to accept the new signature. We can go into the big rebase/merge debate. Linus is in the rebase camp.
  - mh8h 7y ago
    That's because you are not supposed to rebase other people's code on top of a changed base. That can effectively modify the behaviour of their code change. So it's good that the resulting commit won't be signed anymore. And if you are rebasing your own code, then you can sign it again.
    - gus_massa 7y ago
      What about cherrypicking bug fixes to old versions?
      - jimktrains2 7y ago
        Cherry picking creates a new commit.
        gus_massa 7y ago
        The cherry picked comment usually has the same author and date that the original commit. (Note that rebasing also creates a new commit.) One of the latest commits backported to Linux 4.9.something https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.9.y&id=8d8276867b5ac539f1d6e166a028b51c8b1ceda8 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux... Cherrypicked from https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=master&id=060423bfdee3f8bc6e2c1bac97de24d5415e2bc4 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux... Note that the changes are identical, just add ` &&ret` twice, but the line numbers have changed. Also, the cherrypicked version has an additional `Signed-off-by: `.
smitop 7y ago
> the repo "network" This is actually an optimization done by GitHub. It would take up a lot of space if GitHub copied the entire repo every time someone forked it, so they keep all the commits in the original repo. As a side effect, commits in forks are accessible from the original repo since commits from both repos are stored in the same place.
- argd678 7y ago
  How do they know which branch in my fork is mine vs upstream? Or in the case where I modify a forked branch?
  - emmelaich 7y ago
    A branch is just a series of commits; if any one of the commits has a different hash (as this hack will do) then the commit and all following commits will have a different hash. Including the id of the branch (the HEAD).
    - tsm 7y ago
      It's simpler than that: a branch is just a pointer to one specific commit (with a specific SHA)
      - emmelaich 7y ago
        True, but it's both. Just as a link in a linked list is often the list and the node in the list.
  - ajross 7y ago
    It's sort of the reverse: they can't know, from a bare commit ID, what repo it "belongs" to without searching backward from every tag or branch in the repo. (Even that question is malformed: repos have histories and may have contained commits in the past that are no longer ancestors of existing branches or tags). So they just fake it: they look in their database to find any commit with that SHA and put it up. And that database happens (for obvious performance reasons) to be shared between a repo and its forks.
microcolonel 7y ago
Yeah, they would otherwise have to do a bit of work to keep separate maps of the objects in each fork.

jimktrains2 7y ago

I've never really understood Torvalds' reason for not cryptographiclly signing commits. > Btw, there's a final reason, and probably the really real one. Signing each commit is totally stupid. It just means that you automate it, and you make the signature worth less. It also doesn't add any real value, since the way the git DAG-chain of SHA1's work, you only ever need _one_ signature to make all the commits reachable from that one be effectively covered by that one. So signing each commit is simply missing the point. http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...

Aperocky 7y ago
Oh, I've had that at one of the place I used to work at. The git commit tree is signed, and once a team member left no one can create branches any more because all of his commits are now insecure. Yeah that was fun.
Roritharr 7y ago
I guess he's of the school that it doesn't matter who commits the code, it needs to be checked anyway, for bugs or being malicious.
utopian3 7y ago
Unless I am missing something, his point seems to be different. He doesn’t seem to care about the non-repudiation of a user
tux1968 7y ago
Because each commit is in a cryptographically secure chain, when you sign a Git tag it vouches for the referenced commit and all the commits preceding it. This can be done at important moments such as each release.
- jimktrains2 7y ago
  Sure, but in the case presented by great-grand-parent is a leaf commit with an unknown providence. At the very least I don't think it's "totally stupid", even if I know it's not a panacea for all ills.
gus_massa 7y ago
Cryptographically signing the commits makes rebasing impossible (or at least more difficult). In some cases the rebase is very clean, and none of the modified files had changed by other commits. I guess in this case, git can have a rule to keep a "link" to the old commit and accept the old signature as a signature of the new commit. In some cases there are trivial changes, like indentation because someone else added an `if` around the code you are modifying. Sometimes part of the problem has been fixed. Sometimes one of the functions you use has an additional parameter. Sometimes the code has been moved to another file. In this cases it is difficult to automatically detect if the new rebased commit is equal enough to the old commit to accept the new signature. We can go into the big rebase/merge debate. Linus is in the rebase camp.
- mh8h 7y ago
  That's because you are not supposed to rebase other people's code on top of a changed base. That can effectively modify the behaviour of their code change. So it's good that the resulting commit won't be signed anymore. And if you are rebasing your own code, then you can sign it again.
  - gus_massa 7y ago
    What about cherrypicking bug fixes to old versions?
    - jimktrains2 7y ago
      Cherry picking creates a new commit.
      - gus_massa 7y ago
        The cherry picked comment usually has the same author and date that the original commit. (Note that rebasing also creates a new commit.) One of the latest commits backported to Linux 4.9.something https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.9.y&id=8d8276867b5ac539f1d6e166a028b51c8b1ceda8 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux... Cherrypicked from https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=master&id=060423bfdee3f8bc6e2c1bac97de24d5415e2bc4 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux... Note that the changes are identical, just add ` &&ret` twice, but the line numbers have changed. Also, the cherrypicked version has an additional `Signed-off-by: `.

smitop 7y ago

> the repo "network" This is actually an optimization done by GitHub. It would take up a lot of space if GitHub copied the entire repo every time someone forked it, so they keep all the commits in the original repo. As a side effect, commits in forks are accessible from the original repo since commits from both repos are stored in the same place.

argd678 7y ago
How do they know which branch in my fork is mine vs upstream? Or in the case where I modify a forked branch?
- emmelaich 7y ago
  A branch is just a series of commits; if any one of the commits has a different hash (as this hack will do) then the commit and all following commits will have a different hash. Including the id of the branch (the HEAD).
  - tsm 7y ago
    It's simpler than that: a branch is just a pointer to one specific commit (with a specific SHA)
    - emmelaich 7y ago
      True, but it's both. Just as a link in a linked list is often the list and the node in the list.
- ajross 7y ago
  It's sort of the reverse: they can't know, from a bare commit ID, what repo it "belongs" to without searching backward from every tag or branch in the repo. (Even that question is malformed: repos have histories and may have contained commits in the past that are no longer ancestors of existing branches or tags). So they just fake it: they look in their database to find any commit with that SHA and put it up. And that database happens (for obvious performance reasons) to be shared between a repo and its forks.

microcolonel 7y ago

Yeah, they would otherwise have to do a bit of work to keep separate maps of the objects in each fork.