On 05/06/18 18:51, Brandon Williams wrote:
> Currently, while performing packfile negotiation, clients are only
> allowed to specify their desired objects using object ids. This causes
> a vulnerability to failure when an object turns non-existent during
> negotiation, which may happen if, for example, the desired repository is
> provided by multiple Git servers in a load-balancing arrangement.
>
> In order to eliminate this vulnerability, implement the ref-in-want
> feature for the 'fetch' command in protocol version 2. This feature
> enables the 'fetch' command to support requests in the form of ref names
> through a new "want-ref <ref>" parameter. At the conclusion of
> negotiation, the server will send a list of all of the wanted references
> (as provided by "want-ref" lines) in addition to the generated packfile.
>
> Signed-off-by: Brandon Williams <bmwill@xxxxxxxxxx>
> ---
> Documentation/config.txt | 4 +
> Documentation/technical/protocol-v2.txt | 28 ++++-
> t/t5703-upload-pack-ref-in-want.sh | 153 ++++++++++++++++++++++++
> upload-pack.c | 64 ++++++++++
> 4 files changed, 248 insertions(+), 1 deletion(-)
> create mode 100755 t/t5703-upload-pack-ref-in-want.sh
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index ab641bf5a..acafe6c8d 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -3479,6 +3479,10 @@ Note that this configuration variable is ignored if it is seen in the
> repository-level config (this is a safety measure against fetching from
> untrusted repositories).
>
> +uploadpack.allowRefInWant::
> + If this option is set, `upload-pack` will support the `ref-in-want`
> + feature of the protocol version 2 `fetch` command.
> +
> url.<base>.insteadOf::
> Any URL that starts with this value will be rewritten to
> start, instead, with <base>. In cases where some site serves a
> diff --git a/Documentation/technical/protocol-v2.txt b/Documentation/technical/protocol-v2.txt
> index 49bda76d2..8367e09b8 100644
> --- a/Documentation/technical/protocol-v2.txt
> +++ b/Documentation/technical/protocol-v2.txt
> @@ -299,12 +299,21 @@ included in the client's request:
> for use with partial clone and partial fetch operations. See
> `rev-list` for possible "filter-spec" values.
>
> +If the 'ref-in-want' feature is advertised, the following argument can
> +be included in the client's request as well as the potential addition of
> +the 'wanted-refs' section in the server's response as explained below.
> +
> + want-ref <ref>
> + Indicates to the server than the client wants to retrieve a
> + particular ref, where <ref> is the full name of a ref on the
> + server.
> +
> The response of `fetch` is broken into a number of sections separated by
> delimiter packets (0001), with each section beginning with its section
> header.
>
> output = *section
> - section = (acknowledgments | shallow-info | packfile)
> + section = (acknowledgments | shallow-info | wanted-refs | packfile)
> (flush-pkt | delim-pkt)
>
> acknowledgments = PKT-LINE("acknowledgments" LF)
> @@ -319,6 +328,10 @@ header.
> shallow = "shallow" SP obj-id
> unshallow = "unshallow" SP obj-id
>
> + wanted-refs = PKT-LINE("wanted-refs" LF)
> + *PKT-Line(wanted-ref LF)
s/PKT-Line/PKT-LINE/
ATB,
Ramsay Jones
