> I assume you are assuming here that the "push to upstream" doesn't > involve some kind of human verification? If someone tried pushing > something like this to Linus, he would be checking the git diff stats > and git commit structure for things that might look like "developer > negligence". He's been known to complain to subsystem developers in > his own inimitable when the git commit structure looks suspicious, so > I'm pretty sure he would notice this. > > For example, in my use case, I'm authorative over changes in fs/ext4. > So when I pull from Linus's repo, I examine (using "gitk fs/ext4") all > commits coming from upstream that modify fs/ext4. So if someone tries > introducing a change in fs/ext4 coming from "upstream", I will notice. > Then when I request a pull request from Linus, the git pull request > describes what commits are new in my tree that are not in his, and > shows the diffstats from upstream. When Linus verifies my pull, there > are multiple opportunities where he will notice funny business: > > a) He would notice that my origin commit is something that is not in > his upstream tree. > > b) His diffstat is different from my diffstat (since thanks to the > man-in-the middle, the conception of what commits are new in the git > pull request will be different from his). > > c) His diffstat will show that files outside of fs/ext4 have been > modified, which is a red flag that will merit more close examination. > (And if the attacker had tried to introduce a change in fs/ext4, I > would have noticed when I pulled from the man-in-the-middle git > repo.) Yes, we've been considering that these kind of attacks wouldn't be too effective against, let's say, dictator-lieutenant workflows. > > Now, the crazy behavior where github users randomly and promiscuously > do pushes and pull without doing any kind of verification may very > well be dangerous. Yes, we were mostly familiar with this workflow before starting this research. I can see how the "github generation" is open to many attacks of this nature. Would git be interested in integrating a defense that covers users of this nature (which seems to be a growing userbase)? > But so is someone who saves a 80 patch series from > their inbox, and without reading or verifying all of the patches > applies them blindly to their tree using "git am" --- or if they were > using cvs or svn, bulk applied the patches without doing any > verification.... Just out of curiosity, are there known cases of projects in which this has happened (I've noticed that both Git and Linux are quite stringent in their review/merge process so this wouldn't be the case). > > Cheers, Thanks for the insight! -Santiago. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html