Thread (4 messages) flat view 4 messages, 2 authors, 2016-06-15

Re: [RFC PATCH v4 14/26] Add stateless RPC options to upload-pack, receive-pack

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:47:38

"Shawn O. Pearce" [off-list ref] 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help