"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > One approach is to use an HMAC and sign each advertised SHA-1 > during the initial --advertise-refs phase. Requesters then present > the SHA-1 and the HAMC signature in each "want" line, and the > --stateless-rpc phase validates the signatures to ensure they came > from a trusted party. > > The major problem with this approach is the private key management. > All mirrors of that repository need to have a common private key > so they can generate and later verify that HMAC signature. This is > additional complexity, for perhaps not much gain. I am not worried so much about malicious clients getting themselves confused. One simple alternative would be to internally recreate the response the requestee would send if it were the first phase request upon receiving the request for the second phase---then you take an SHA-1 hash of it. In the second phase request have the requestor include the SHA-1 hash of what it received in the response to its first phase request, and the requestee can make sure they match. No per-ref signing nor secret key management is necessary, and it would let the requestor retry if you allow the response to the second phase request to be "your request is stale, try again". > A different approach is to have the --stateless-rpc phase validate > the want lines against its refs (like we do now), but if the validate > fails (no ref exactly matches) support walking backwards through the > last few records in the reflog, or through that ref's own history > for a few hundred commits, to see if the want SHA-1 appears in the > recent prior past. > > Obviously when walking the reflog we would need to use a time bound, > e.g. "only examine last record if more recent than 5 minutes ago". I think that is probably too much complexity for too little gain. I think detecting stale request and having requestor retry would be sufficient, and validating the want lines as we already do would give the same level of assurance as "check against the hash of first phase response" I outlined above, and would be much simpler thus more robust. -- 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