On Fri, 16 Jun 2006, Alexander Litvinov wrote: > > I have found the ability to hack git repo. After this hacking people will > checkout hacked files from the "trusted" commit. Only git-fsck-objects will > complain at this. Right. If you can't trust your local filesystem, you are screwed. git-fsck-objects will notice when somebody has done something bad, but > Why does not git-checkout check if file content match name of the object ? Why would it? It really just slows things down, and if you don't trust your local repo, people can "hack" you much more easily by just generating a _proper_ tree with the _proper_ data, and git checkout checking the SHA1 wouldn't help at all. The way to security lies in using git-fsck-objects, together with an _external_ source of trust. For example, that external source of trust may be a signed tag, or, perhaps even more simply, just by saving off the top commit name on some trusted medium. But you do need a "point of trust" to start with. Without that, it's a lot easier to "hack" a git repo by doing echo 'Hacked file' > a git commit --amend a git prune and now the file "a" has changed to "Hacked file", and even git-fsck-objects can't tell that anything bad happened. (Btw, if you want to _hide_ the fact that "a" now contains "Hacked file", you do so by faking it in the index. You can have the checked-out copy say what it should say - ie "Usual file" - and if you don't want git to show you the difference to HEAD, you edit the .git/index file by hand so that the timestamp, size and inode matches the real SHA1, even though the _contents_ match "Usual file"). See? You do need to trust something. Normally you'd trust your own filesystem, but git certainly supports other forms of trust through either the native support for signed certificates in the form of tags, or any other form of external trust. Linus - : 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