On Sat, Mar 3, 2012 at 12:31 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Not everything is valid, then. Objects from new packs are, existing >> ones may be guilty. If there is a way to mark new packs trusted, then >> we only need to validate the other objects, which should be the >> minority or even empty unless an attack is mounted. > > Yes, but how? Running "fsck" on all of pre-existing objects every time > you fetch (or accept push) is not an answer. > > If your fetch did not explode the incoming pack into pieces, a possibility > is to still use the --verify-object codepath, but pass the identity of the > pack (e.g. struct packed_git) down the callchain so that you can avoid > rehashing the objects that came from that single pack, but that would not > help the case where you ended up calling unpack-objects. It won't help the unpack-objects case. But unpack-objects is only used when the pack has less than a certain number of objects, doing heavy check in that case should not take too long. Yes, I was thinking I would pass pack identity down the verify-pack callchain for index-pack case. > I also suspect that more than trivial amount of computation is needed to > determine if a given object exists only in a single pack, so the end > result may not be that much cheaper than the current --verify-object code. Objects can exist in multiple packs right now if they are base objects. I'm not sure why you need to check for object existence in a single pack. index-pack tries to make sure duplicate objects with the same sha-1 must be identical, content-wise. Though it does not do that hard enough (i.e. only check with one in-repo instance of the object, instead of all of them). -- Duy -- 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