Kyle Lippincott <spectral@xxxxxxxxxx> writes: >> > But that implies you trust Git's object hash algorithm. >> >> Right -- I think anything but bit-by-bit identical files is going to be >> too complex to verify. > > I'm curious what specific attacks you're trying to catch here. Because > to get into a situation where you unbundle the bundle and have the > same commit hash but different contents, you would need to have a > collision in the SHA-1 hash for some object (or SHA-256 hash if the > repo is using that). If you're also providing the instructions (or > even just the commit hash and server to clone from, and linking to > instructions maintained elsewhere) to validate the bundle is > legitimate, it seems MUCH easier to just replace those validation > instructions to point to a commit/server that has already been > backdoored than it would be to generate a SHA-1 collision that would > go undetected. I think there are two levels of "verify" involved in this discussion. There are those who want to trust bundles and and place enough trust on whoever created that bundle. They are happy as long as the bitstream they received the first time does not change when they ask for it for the second time, because they at least know that the same input would result in the same output. To them, "attack" is what changes the bitstream while they are looking the other way. They do not like the fact that there can be more than one representations of the same thing for this reason. Then there are those who know Git enough to know that they do not need to trust the middleman who create bundle files, and they do not need to trust exact bitstream that is contained within these bundle files. They can extract the bundle to verify the tip commits of the history (by comparing their object names with published hashes, by verifying the embedded signatures, etc.), which is what ensures integrity in Merkle tree based systems like history stored in Git. The latter folks may worry about the "attacks" you mention here, but the former may not necessarily do so.
