Re: Dropping '+' from fetch = +refs/heads/*:refs/remotes/origin/*?
- From
Michael J Gruber <git@drmicha.warpmail.net>
- Date
- Sep 6, 2011, 07:51 UTC
- 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:
Show 11 quoted lines
> 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