Re: Security problem

From: Alexander Litvinov <lan@academsoft.ru>
Date: Jun 16, 2006, 05:37 UTC
Message-ID: <200606161237.21997.lan@academsoft.ru>
In-Reply-To: <Pine.LNX.4.64.0606152137410.5498@g5.osdl.org>

> 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.

Show 5 quoted lines

> 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 :-)

Show 6 quoted lines

>  - 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 !