On Sun, 2016-10-30 at 01:16 -0700, Junio C Hamano wrote: > Jon Loeliger <jdl@xxxxxxx> writes: > > > > > Is there an existing protocol provision, or an extension to > > the protocol that would allow a distrustful client to say to > > the server, "Really, you have Y2? Prove it." > > There is not, but I do not think it would be an effective solution. > > The issue is not the lack of protocol support, but how to determine > that the other side needs such a proof for Y2 but not for other > commits. How does your side know what makes Y2 special and why does > yout side think they should not have Y2? > > Once you know how to determine Y2 is special, that knowledge can be > used to abort the "push" before even starting. When you are pushing > back the 'master' and that 'master' reaches Y2, which must be kept > secret, you shouldn't be pushing that 'master' to them, whether they > claim to have Y2 or not. FWIW, I can imagine a protocol that would prove possession for all objects, which would completely fix the problem. Each object would have a "private" hash computed recursively over the object graph, just like the ordinary object hash, but with a different seed. The object database would be extended to cache the private hash of every object. Then, during a fetch or push, when the two sides identify a matching object, the side that would otherwise have had to send the object sends the private hash. Support for storing multiple hashes per object might also be useful in some way for the migration to a stronger hash function than SHA-1. The next best solution, which doesn't require a protocol change but requires a little user intervention, is to have a configuration option per remote for a set of refs whose reachable objects are known to be safe to send to the server. This set presumably includes the remote's own remote-tracking refs. During fetch and push, the client looks for matches only among these "safe" objects, effectively emulating a repository containing only the safe objects. A fetch may update the remote-tracking refs to point to unsafe objects that were already in the local repository, effectively making them safe, but only after the server sends the content of these objects (and the client validates the hashes!). Unfortunately, I'm not signing up to implement either solution. :( Matt