Matthieu Moy venit, vidit, dixit 06.09.2011 09:39: > Shawn Pearce <spearce@xxxxxxxxxxx> 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 -- To unsubscribe from this list: 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