> Well, they may not be "safe" - you just need to work a _lot_ harder to > corrupt a pack-file in any interesting manner. And again, git-fsck-objects > would pick up any such thing going on. As it shown in pack-objects.c, each object have stored sha1, almost the same as file rename. > The first is that git-fsck-objects will definitely find any repository > inconsistency, and to get around that, you either have to get around the > basic properties of SHA-1 (ie break the hash) _or_ you have to actually > change the repository so that it's still a valid repo, just with different > content. I still belive SHA-1 is good enouth to hash files - I did not hear about generation reasonable duplicate that can compile and work :-) > - if you corrupt the repository, subsequent clones (or even pulls) from > the corrupt repository simply won't work if you use the native > protocol, because the native protocol doesn't actually trust anything > but the actual contents (so if the contents won't match, then neither > will the SHA1 names). So the corruption is pretty strictly limited to > the _one_ repository that the attacker had write access to. As I understand sent pack file will contains actial SHA-1 of objects. And any hack will be cleary visible. > So there's a pretty fundamental "corruption containment" part there. ... Situation with evil repo is clear to me: you can turst only to trusted commit identified by SHA-1 > But yeah, I actually still personally do a fair number of > "git-fsck-objects". I've never found anything that way since very early on > (and back then, the real problem was rsync getting objects that weren't > reachable), but I still do it. It makes me feel happier. As the result: Always fsck repo after pull/clone ! - : 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