On Mon, Sep 05, 2011 at 11:15:26AM -0700, Shawn O. Pearce wrote: > > One possible solution is that the local config could dynamically depend > > on the remote config. E.g., the fetch refspec has something like a > [...] > > What are we trying to do here? We veered way off topic into the idea of generally pulling config from a remote. This was just one specific example of how it could be used, and what kinds of complications that might entail. > If the attacker knows Git clients always fetch rewinds, he might be > tempted to rewrite some part of history and serve his modified history > of events to clients. But the repository owner (if using a private > per-user repository model like the Linux kernel developers use) would > notice on their next push, and sound the alarm that her repository has > been damaged and should not be trusted. > > If on the other hand Git clients never fetch rewinds, the attacker > would just add a new commit to the tip of the history, and serve that. > Again, the repository owner would notice on their next push, and > notify people the repository is not to be trusted. > > Either way, the "+" in the fetch spec has no impact on the attack. The > default just changes the attacker's choices slightly. Exactly. This is what I was hinting at in my original email in this thread. My gut feeling is that it's not useful as a security measure, but I was trying to challenge people to prove me wrong by showing a case where the attacker can't just trivially modify his attack to get the same result. > Maybe instead of getting a project policy from the server, we observe > the server's behavior over time from the client's reflog. If every > update to "maint" that _I_ have observed has always been a > fast-forward, a rewind on that branch should be a lot more verbose in > the fetch output than "force update". That is pretty easy to observe > from the reflog too, its just a scan of the records and either > matching the message, or checking the merge status of the old-new > pairs listed in the record. We don't even need to read the entire log > on every fetch, we could cache this data. Hmm. That would probably work most of the time in practice. But it seems like it would be quite confusing when the heuristic is wrong (e.g., Junio rewinds next once every few months, and other than that, it always fast forwards). On the other hand, if the failure mode of the heuristic is only a slightly bigger warning, then it's not that big a deal. > The main reason to alert the user that a branch rewound is to give > them a chance to correct their client if they need to. If a branch > normally doesn't rewind (e.g. next) but then suddenly does (e.g. > release cycle), but I haven't used this client in 3 weeks, its nice to > give me more of a "HEY STUPID FIX YOUR TOPICS" warning than just the > little quiet "force update" we give. Sure. I'm totally open to the idea of making the non-fast-forward warning more obvious. Suggestions for wording (though I am tempted by "HEY STUPID" above ;) )? -Peff -- 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