[fryguy]

That's not entirely true. You could fork a popular git repo, and then make some kind of patch for a bug in some seldomly changed file. Then force a collision in the new file with the benign change as well as your poisoned version. Then they could convince you to pull in the changes. Then they could reset their repository to the one with the poisoned version and anyone who pulls from them first would get the poisoned version of the file instead of the right one. It seems extremely unlikely that a practical attack would come out of this though.

[disiplus]

thats stretching it. if you could convince anybody to pull from you then why even bother to go to a great expense of creating a collision.

[victorNicollet]

This reminds me of vulnerability reports that start with "if you have root access..."

[erbo]

Or, as Raymond Chen puts it (quoting Douglas Adams), "It rather involved being on the other side of this airtight hatchway."

[sqeaky]

It creates plausible dependability.

Imagine the NSA publishing a crypto algorithm and contributes it to openSSL or some hypothetical crypto library using git. If they commit their new algorithm, everyone will be looking at that. They could do something devious like tinker with the way random numbers are generated elsewhere and reduce the possible keyspace of another algorithm to something very small and easy to brute force.

When this keyspace shortening is found out it would be hard or impossible to track back. No amount of inspecting the files that reportedly changed would reveal that the NSA did this.