From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Tue, 06 Sep 2011 07:51:56 GMT
Subject: Re: Dropping '+' from fetch = +refs/heads/*:refs/remotes/origin/*?
Message-ID: <4E65D11C.3050105@drmicha.warpmail.net>
In-Reply-To: <vpqvct69l2e.fsf@bauges.imag.fr>

Matthieu Moy venit, vidit, dixit 06.09.2011 09:39:
> Shawn Pearce <spearce@spearce.org> writes:
> 
>> Again, the repository owner would notice on their next push, and
>> notify people the repository is not to be trusted.
> 
> For simple attack, yes. But if the server is compromised, you can't
> trust it anymore to error out on non-fast-forward. I don't think it
> would be very complex to write a modified Git server that would come
> back to the official history before a push, and re-introduce faulty
> commits right after. pushers wouldn't notice, and fetchers would get
> compromised history.

Exactly. Even on fetch, it could serve different histories depending on
the ip so that the pusher does not notice when fetching from the same ip.

> OTOH, non-fast-forward fetches can be reliably detected client-side, and
> I like being able to think "whatever the server does, I don't care
> because I'm using Git".

reflog based warnings should provide a sane default. We could amend the
update hook for those who want to allow/deny specific branches to
rewind, or make receiveDeny... branch.-specific, if the multiple
refspecs approach is too complicated.

Michael