4 ms·

That's not the attack on git -- it's the commit ID. You can have two patches that have the same commit. Apply one now, and in the future replace it with the sec

That's not the attack on git -- it's the commit ID. You can have two patches that have the same commit. Apply one now, and in the future replace it with the second one, without affecting any other commits IDs afterwards.

0x0 10y ago
But I thought files in git were also identified by the sha1 of their contents? Why isn't there a conflict/de-duplication happening when committing one file over the other? I must be misunderstanding something, but I thought the commit points to a hash of a tree (file list) which has a list of blobs (file referenced by their sha1 sum), how does it know which of the two pdf file blobs to pick out of the blob store?
- anilgulecha 10y ago
  No, each commit (or merge) is simply the SHA1 of the diff-patch. Thus adding the second file does create a diff, since the contents are not the same.
  - kinkrtyavimoodh 10y ago
    No, a commit is not the SHA-1 of the diff. The fundamental object model of Git does not store diffs, it stores the actual state of the source tree as represented by a commit. For instance, here's a commit file [1]— $ git cat-file -p fdf4fc3 tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579 author Scott Chacon <schacon@gmail.com> 1243040974 -0700 committer Scott Chacon <schacon@gmail.com> 1243040974 -0700 first commit A commit object just points to the tree object (in turn, another SHA-1, this time of the complete directory listing) and other meta information such as author name etc. [1] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
    - anilgulecha 10y ago
      Correct -- I was being terse: the commit is a function of the changes going in (and metadata like time, authorship). Details: https://gist.github.com/masak/2415865 https://gist.github.com/masak/2415865
      - 0x0 10y ago
        I'm not really talking about entire git commits, but just single files (blobs) within any commit/tree/repository
      - chronial 10y ago
        That is not correct and also not supported by your link. A git commit does not contain any changes. It is always a full sapshot of the repo state. To have any kind of concept of "change", you need two gït commits. Just like a simple text file.
- deathanatos 10y ago
  It's not simply a sha1(contents), but sha1(header + contents); the addition of that header means that SHA1's internal state is different from what it was in the raw PDFs when we encounter the section of the PDF that — without the header — would cause the internal state to align in the two PDFs. So, the header throws things off. But, if you took the header into account, redid the giant computation that Google did, then you could get two PDFs with different SHA1 hashes that, when committed (and thus get the header added) hash to the same thing.

0x0 10y ago

But I thought files in git were also identified by the sha1 of their contents? Why isn't there a conflict/de-duplication happening when committing one file over the other? I must be misunderstanding something, but I thought the commit points to a hash of a tree (file list) which has a list of blobs (file referenced by their sha1 sum), how does it know which of the two pdf file blobs to pick out of the blob store?

anilgulecha 10y ago
No, each commit (or merge) is simply the SHA1 of the diff-patch. Thus adding the second file does create a diff, since the contents are not the same.
- kinkrtyavimoodh 10y ago
  No, a commit is not the SHA-1 of the diff. The fundamental object model of Git does not store diffs, it stores the actual state of the source tree as represented by a commit. For instance, here's a commit file [1]— $ git cat-file -p fdf4fc3 tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579 author Scott Chacon <schacon@gmail.com> 1243040974 -0700 committer Scott Chacon <schacon@gmail.com> 1243040974 -0700 first commit A commit object just points to the tree object (in turn, another SHA-1, this time of the complete directory listing) and other meta information such as author name etc. [1] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
  - anilgulecha 10y ago
    Correct -- I was being terse: the commit is a function of the changes going in (and metadata like time, authorship). Details: https://gist.github.com/masak/2415865 https://gist.github.com/masak/2415865
    - 0x0 10y ago
      I'm not really talking about entire git commits, but just single files (blobs) within any commit/tree/repository
    - chronial 10y ago
      That is not correct and also not supported by your link. A git commit does not contain any changes. It is always a full sapshot of the repo state. To have any kind of concept of "change", you need two gït commits. Just like a simple text file.
deathanatos 10y ago
It's not simply a sha1(contents), but sha1(header + contents); the addition of that header means that SHA1's internal state is different from what it was in the raw PDFs when we encounter the section of the PDF that — without the header — would cause the internal state to align in the two PDFs. So, the header throws things off. But, if you took the header into account, redid the giant computation that Google did, then you could get two PDFs with different SHA1 hashes that, when committed (and thus get the header added) hash to the same thing.