On Mon, 28 Aug 2006, Jeff King wrote: > > On Mon, Aug 28, 2006 at 10:56:01AM -0700, Linus Torvalds wrote: > > > However, the "earlier will override" is very much what you want from a > > security standpoint: remember that the git model is that you should > > primarily trust only your _own_ repository. So if you do a "git pull", the > > This concept breaks down somewhat if you are pulling from two > repositories (one good and one evil). If I pull from the evil repo > first, that will become my "earlier" object, and I will never get the > colliding object from the good repo. Sure. But if you are pulling from an untrusted source, you'd better at least check the result. In fact, that's partly why "git pull" will do a diffstat after the pull. Exactly to force people to at least be minimally aware of what they pulled. And "gitk ORIG_HEAD.." is a great thing to always run when you pull from somebody you don't know and trust really well. Of course, that all was done mostly not because I don't "trust" the people I work with, but more because I didn't always trust that they'd do the right thing with git (ie they'd screw up the repo not because they were evil, but because they made a mistake). So even if you pull from an "evil" repo first, and you somehow get a "bad" object, the point is, the bad object _should_ be the one that overrides. Why? Because once you find out that the evil repo was bad (which you'll eventually find simply because it caused some bug - if the evil repo only helps you, it's obviously not evil at all), what you need to do is reset to _before_ the evil repo happened, do a "git repack -a -d" and finally a "git prune" to clean out all the bad cruft, and then pull the good repo without pulling the bad one first. After that, you apologize to everybody for screwing up and pulling from somebody you didn't trust, and then ask them to re-clone (or give them the appropriate "git reset" + "git repack -a" + "git prune" + "git pull" sequence so that they can fix their existing repos). The point being, a hash attack is really no worse than an attack that fools you into applying a really bad diff (regardless of SCM), and it's a hell of a lot harder to do. Both a hash attack and a diff attack mean that the person merging data should either trust his source or inspect the end result. Anybody who just blindly accepts data from untrusted sources is screwed in so many other ways that the hash attack simply isn't even on the radar. Linus - 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