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

[Junio C Hamano <gitster@pobox.com>]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> When --stateless-rpc is passed as a command line parameter to
> upload-pack or receive-pack the programs now assume they may
> perform only a single read-write cycle with stdin and stdout.
> This fits with the HTTP POST request processing model where a
> program may read the request, write a response, and must exit.
>
> When --advertise-refs is passed as a command line parameter only
> the initial ref advertisement is output, and the program exits
> immediately.  This fits with the HTTP GET request model, where
> no request content is received but a response must be produced.

Is the idea to first run with --advertise-refs to get the set of refs, and
then doing another, separate run with --stateless-rpc, assuming that the
refs the other end advertised does not change in the meantime, to conclude
the business?

I suspect that two separate invocations on a (supposedly) single
repository made back-to-back can produce an inconsistent response in
verious situations (e.g. somebody pushing in the middle, or the same
hostname served by more than one mirrors) and the other end can get
confused.

I do not think there is any way to avoid it, short of adding to the second
request some "cookie" that allows the second requestee to verify that the
request is based on what he would give to the requester if this request
were the first step of the request made to him, iow, his state did not
change in the middle since the first request was made (either to him or to
the equivalent mirror sitting next to himm).

I wouldn't worry too much about this if the only negative effect could be
that the requestor's second request may result in an error, but I am
wondering if this can be used to attack the requestee.