4 ms·

I guess the best an attacker could hope for would be to modify the git binaries on the server. Even that would amount to little it seems.

by bsiemon 15y ago

extension 15y ago
If they could slip something into the git source then from there, they could tamper with any git project undetected. But since git is presumably self-hosted, it would still be profoundly difficult to get everyone to upgrade to the evil git without noticing the attack. It would require some devilishly underhanded code: http://underhanded.xcott.com/ http://underhanded.xcott.com/
- tonfa 15y ago
  Given the number of changes coming in every release, and since some people rebase, a hash change might not be detected...
  - Xurinos 15y ago
    Speaking as a regular git user, I assure you that a hash change would be noticeable. Rebase would look for a common hash between your history and the remote history you just fetched and rebase your commits on top of it. When there is a mismatch, you experience a twilight zone where there are attempted merges of code that your changes had nothing to do with. At this point, it is apparent the remote history has changed, and in the process of trying to figure out how to rebase cleanly, your eyes will be on that foreign code. Given the number of changes coming in every release, more twilight zone experiences increases the number of eyes on the discrepancy. I am confident in the sanctity of the git-sourced code, thanks to there being multiple version of the same repository around that people are actively working on. I am more worried about all the stuff I might rely on that is not git-sourced.
    - tonfa 15y ago
      If the history is tampered during a rebase how would you notice? Suppose a tree well known for rebasing frequently is rebased on kernel.org, and the dev doing it works from the k.org servers (might be possible, since they give shell access). Then downstream would just see it as yet another rebase, no?
      - Xurinos 15y ago
        Is this the hypothetical situation of someone doing an interactive rebase on public/published branches and making changes midway through? My current understanding is that, although it is possible, the community avoids doing that (policy: published code history set in stone). That style requires strong communication between developers. It makes people do extra investigation and work, and we all hate doing extra work, right? :) I cannot speak for what they really do over at kernel.org, but if they do rebase their public repositories often (which will break people doing pushes and fetch/merges without some regular communication), yes, it is possible to sneak something in because the public rebase will not be as exceptional. This is where you tell me that's what they do there and make me scared again. ;)

I guess the best an attacker could hope for would be to modify the git binaries on the server. Even that would amount to little it seems.

by bsiemon 15y ago

I guess the best an attacker could hope for would be to modify the git binaries on the server. Even that would amount to little it seems.

extension 15y ago

If they could slip something into the git source then from there, they could tamper with any git project undetected. But since git is presumably self-hosted, it would still be profoundly difficult to get everyone to upgrade to the evil git without noticing the attack. It would require some devilishly underhanded code: http://underhanded.xcott.com/ http://underhanded.xcott.com/

tonfa 15y ago
Given the number of changes coming in every release, and since some people rebase, a hash change might not be detected...
- Xurinos 15y ago
  Speaking as a regular git user, I assure you that a hash change would be noticeable. Rebase would look for a common hash between your history and the remote history you just fetched and rebase your commits on top of it. When there is a mismatch, you experience a twilight zone where there are attempted merges of code that your changes had nothing to do with. At this point, it is apparent the remote history has changed, and in the process of trying to figure out how to rebase cleanly, your eyes will be on that foreign code. Given the number of changes coming in every release, more twilight zone experiences increases the number of eyes on the discrepancy. I am confident in the sanctity of the git-sourced code, thanks to there being multiple version of the same repository around that people are actively working on. I am more worried about all the stuff I might rely on that is not git-sourced.
  - tonfa 15y ago
    If the history is tampered during a rebase how would you notice? Suppose a tree well known for rebasing frequently is rebased on kernel.org, and the dev doing it works from the k.org servers (might be possible, since they give shell access). Then downstream would just see it as yet another rebase, no?
    - Xurinos 15y ago
      Is this the hypothetical situation of someone doing an interactive rebase on public/published branches and making changes midway through? My current understanding is that, although it is possible, the community avoids doing that (policy: published code history set in stone). That style requires strong communication between developers. It makes people do extra investigation and work, and we all hate doing extra work, right? :) I cannot speak for what they really do over at kernel.org, but if they do rebase their public repositories often (which will break people doing pushes and fetch/merges without some regular communication), yes, it is possible to sneak something in because the public rebase will not be as exceptional. This is where you tell me that's what they do there and make me scared again. ;)