global: introduce `USE_THE_REPOSITORY_VARIABLE` macro
Use of the `the_repository` variable is deprecated nowadays, and we
slowly but steadily convert the codebase to not use it anymore. Instead,
callers should be passing down the repository to work on via parameters.
It is hard though to prove that a given code unit does not use this
variable anymore. The most trivial case, merely demonstrating that there
is no direct use of `the_repository`, is already a bit of a pain during
code reviews as the reviewer needs to manually verify claims made by the
patch author. The bigger problem though is that we have many interfaces
that implicitly rely on `the_repository`.
Introduce a new `USE_THE_REPOSITORY_VARIABLE` macro that allows code
units to opt into usage of `the_repository`. The intent of this macro is
to demonstrate that a certain code unit does not use this variable
anymore, and to keep it from new dependencies on it in future changes,
be it explicit or implicit
For now, the macro only guards `the_repository` itself as well as
`the_hash_algo`. There are many more known interfaces where we have an
implicit dependency on `the_repository`, but those are not guarded at
the current point in time. Over time though, we should start to add
guards as required (or even better, just remove them).
Define the macro as required in our code units. As expected, most of our
code still relies on the global variable. Nearly all of our builtins
rely on the variable as there is no way yet to pass `the_repository` to
their entry point. For now, declare the macro in "biultin.h" to keep the
required changes at least a little bit more contained.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-14 14:50:23 +08:00
|
|
|
#define USE_THE_REPOSITORY_VARIABLE
|
|
|
|
|
2023-02-24 08:09:23 +08:00
|
|
|
#include "git-compat-util.h"
|
2018-03-16 01:31:19 +08:00
|
|
|
#include "repository.h"
|
|
|
|
#include "config.h"
|
2024-06-14 14:50:32 +08:00
|
|
|
#include "hash.h"
|
2018-03-16 01:31:19 +08:00
|
|
|
#include "pkt-line.h"
|
|
|
|
#include "version.h"
|
2018-03-16 01:31:20 +08:00
|
|
|
#include "ls-refs.h"
|
2021-04-21 07:38:31 +08:00
|
|
|
#include "protocol-caps.h"
|
2018-03-16 01:31:19 +08:00
|
|
|
#include "serve.h"
|
2018-03-16 01:31:27 +08:00
|
|
|
#include "upload-pack.h"
|
2022-12-22 23:14:07 +08:00
|
|
|
#include "bundle-uri.h"
|
2023-02-24 08:09:23 +08:00
|
|
|
#include "trace2.h"
|
2018-03-16 01:31:19 +08:00
|
|
|
|
2021-08-05 09:25:39 +08:00
|
|
|
static int advertise_sid = -1;
|
upload-pack: disallow object-info capability by default
We added an "object-info" capability to the v2 upload-pack protocol in
a2ba162cda (object-info: support for retrieving object info,
2021-04-20). In the almost 3 years since, we have not added any
client-side support, and it does not appear to exist in other
implementations either (JGit understands the verb on the server side,
but not on the client side).
Since this largely unused code is accessible over the network by
default, it increases the attack surface of upload-pack. I don't know of
any particularly severe problem, but one issue is that because of the
request/response nature of the v2 protocol, it will happily read an
unbounded number of packets, adding each one to a string list (without
regard to whether they are objects we know about, duplicates, etc).
This may be something we want to improve in the long run, but in the
short term it makes sense to disable the feature entirely. We'll add a
config option as an escape hatch for anybody who wants to develop the
feature further.
A more gentle option would be to add the config option to let people
disable it manually, but leave it enabled by default. But given that
there's no client side support, that seems like the wrong balance with
security.
Disabling by default will slow adoption a bit once client-side support
does become available (there were some patches[1] in 2022, but nothing
got merged and there's been nothing since). But clients have to deal
with older servers that do not understand the option anyway (and the
capability system handles that), so it will just be a matter of servers
flipping their config at that point (and hopefully once any unbounded
allocations have been addressed).
[jk: this is a patch that GitHub has been running for several years, but
rebased forward and with a new commit message for upstream]
[1] https://lore.kernel.org/git/20220208231911.725273-1-calvinwan@google.com/
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-02-29 06:38:58 +08:00
|
|
|
static int advertise_object_info = -1;
|
2021-09-15 07:51:27 +08:00
|
|
|
static int client_hash_algo = GIT_HASH_SHA1;
|
2020-11-12 07:29:29 +08:00
|
|
|
|
2023-02-24 14:38:23 +08:00
|
|
|
static int always_advertise(struct repository *r UNUSED,
|
|
|
|
struct strbuf *value UNUSED)
|
2018-03-16 01:31:20 +08:00
|
|
|
{
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2023-02-24 14:38:23 +08:00
|
|
|
static int agent_advertise(struct repository *r UNUSED,
|
2018-03-16 01:31:19 +08:00
|
|
|
struct strbuf *value)
|
|
|
|
{
|
|
|
|
if (value)
|
|
|
|
strbuf_addstr(value, git_user_agent_sanitized());
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2020-05-26 03:59:17 +08:00
|
|
|
static int object_format_advertise(struct repository *r,
|
|
|
|
struct strbuf *value)
|
|
|
|
{
|
|
|
|
if (value)
|
|
|
|
strbuf_addstr(value, r->hash_algo->name);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2023-02-24 14:38:23 +08:00
|
|
|
static void object_format_receive(struct repository *r UNUSED,
|
2021-09-15 07:51:27 +08:00
|
|
|
const char *algo_name)
|
|
|
|
{
|
|
|
|
if (!algo_name)
|
|
|
|
die("object-format capability requires an argument");
|
|
|
|
|
|
|
|
client_hash_algo = hash_algo_by_name(algo_name);
|
|
|
|
if (client_hash_algo == GIT_HASH_UNKNOWN)
|
|
|
|
die("unknown object format '%s'", algo_name);
|
|
|
|
}
|
|
|
|
|
2020-11-12 07:29:29 +08:00
|
|
|
static int session_id_advertise(struct repository *r, struct strbuf *value)
|
|
|
|
{
|
2021-08-05 09:25:39 +08:00
|
|
|
if (advertise_sid == -1 &&
|
2023-02-24 14:38:10 +08:00
|
|
|
repo_config_get_bool(r, "transfer.advertisesid", &advertise_sid))
|
2021-08-05 09:25:39 +08:00
|
|
|
advertise_sid = 0;
|
2020-11-12 07:29:29 +08:00
|
|
|
if (!advertise_sid)
|
|
|
|
return 0;
|
|
|
|
if (value)
|
|
|
|
strbuf_addstr(value, trace2_session_id());
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2023-02-24 14:38:23 +08:00
|
|
|
static void session_id_receive(struct repository *r UNUSED,
|
2021-09-15 07:51:30 +08:00
|
|
|
const char *client_sid)
|
|
|
|
{
|
|
|
|
if (!client_sid)
|
|
|
|
client_sid = "";
|
|
|
|
trace2_data_string("transfer", NULL, "client-sid", client_sid);
|
|
|
|
}
|
|
|
|
|
upload-pack: disallow object-info capability by default
We added an "object-info" capability to the v2 upload-pack protocol in
a2ba162cda (object-info: support for retrieving object info,
2021-04-20). In the almost 3 years since, we have not added any
client-side support, and it does not appear to exist in other
implementations either (JGit understands the verb on the server side,
but not on the client side).
Since this largely unused code is accessible over the network by
default, it increases the attack surface of upload-pack. I don't know of
any particularly severe problem, but one issue is that because of the
request/response nature of the v2 protocol, it will happily read an
unbounded number of packets, adding each one to a string list (without
regard to whether they are objects we know about, duplicates, etc).
This may be something we want to improve in the long run, but in the
short term it makes sense to disable the feature entirely. We'll add a
config option as an escape hatch for anybody who wants to develop the
feature further.
A more gentle option would be to add the config option to let people
disable it manually, but leave it enabled by default. But given that
there's no client side support, that seems like the wrong balance with
security.
Disabling by default will slow adoption a bit once client-side support
does become available (there were some patches[1] in 2022, but nothing
got merged and there's been nothing since). But clients have to deal
with older servers that do not understand the option anyway (and the
capability system handles that), so it will just be a matter of servers
flipping their config at that point (and hopefully once any unbounded
allocations have been addressed).
[jk: this is a patch that GitHub has been running for several years, but
rebased forward and with a new commit message for upstream]
[1] https://lore.kernel.org/git/20220208231911.725273-1-calvinwan@google.com/
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-02-29 06:38:58 +08:00
|
|
|
static int object_info_advertise(struct repository *r, struct strbuf *value UNUSED)
|
|
|
|
{
|
|
|
|
if (advertise_object_info == -1 &&
|
|
|
|
repo_config_get_bool(r, "transfer.advertiseobjectinfo",
|
|
|
|
&advertise_object_info)) {
|
|
|
|
/* disabled by default */
|
|
|
|
advertise_object_info = 0;
|
|
|
|
}
|
|
|
|
return advertise_object_info;
|
|
|
|
}
|
|
|
|
|
2018-03-16 01:31:19 +08:00
|
|
|
struct protocol_capability {
|
|
|
|
/*
|
|
|
|
* The name of the capability. The server uses this name when
|
|
|
|
* advertising this capability, and the client uses this name to
|
|
|
|
* specify this capability.
|
|
|
|
*/
|
|
|
|
const char *name;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Function queried to see if a capability should be advertised.
|
|
|
|
* Optionally a value can be specified by adding it to 'value'.
|
|
|
|
* If a value is added to 'value', the server will advertise this
|
|
|
|
* capability as "<name>=<value>" instead of "<name>".
|
|
|
|
*/
|
|
|
|
int (*advertise)(struct repository *r, struct strbuf *value);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Function called when a client requests the capability as a command.
|
2021-08-05 09:25:38 +08:00
|
|
|
* Will be provided a struct packet_reader 'request' which it should
|
2018-03-16 01:31:19 +08:00
|
|
|
* use to read the command specific part of the request. Every command
|
|
|
|
* MUST read until a flush packet is seen before sending a response.
|
|
|
|
*
|
|
|
|
* This field should be NULL for capabilities which are not commands.
|
|
|
|
*/
|
2021-08-05 09:25:38 +08:00
|
|
|
int (*command)(struct repository *r, struct packet_reader *request);
|
2021-09-14 23:31:07 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Function called when a client requests the capability as a
|
|
|
|
* non-command. This may be NULL if the capability does nothing.
|
|
|
|
*
|
|
|
|
* For a capability of the form "foo=bar", the value string points to
|
|
|
|
* the content after the "=" (i.e., "bar"). For simple capabilities
|
|
|
|
* (just "foo"), it is NULL.
|
|
|
|
*/
|
|
|
|
void (*receive)(struct repository *r, const char *value);
|
2018-03-16 01:31:19 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
static struct protocol_capability capabilities[] = {
|
2021-08-05 09:25:37 +08:00
|
|
|
{
|
|
|
|
.name = "agent",
|
|
|
|
.advertise = agent_advertise,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "ls-refs",
|
|
|
|
.advertise = ls_refs_advertise,
|
|
|
|
.command = ls_refs,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "fetch",
|
|
|
|
.advertise = upload_pack_advertise,
|
|
|
|
.command = upload_pack_v2,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "server-option",
|
|
|
|
.advertise = always_advertise,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "object-format",
|
|
|
|
.advertise = object_format_advertise,
|
2021-09-15 07:51:27 +08:00
|
|
|
.receive = object_format_receive,
|
2021-08-05 09:25:37 +08:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "session-id",
|
|
|
|
.advertise = session_id_advertise,
|
2021-09-15 07:51:30 +08:00
|
|
|
.receive = session_id_receive,
|
2021-08-05 09:25:37 +08:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "object-info",
|
upload-pack: disallow object-info capability by default
We added an "object-info" capability to the v2 upload-pack protocol in
a2ba162cda (object-info: support for retrieving object info,
2021-04-20). In the almost 3 years since, we have not added any
client-side support, and it does not appear to exist in other
implementations either (JGit understands the verb on the server side,
but not on the client side).
Since this largely unused code is accessible over the network by
default, it increases the attack surface of upload-pack. I don't know of
any particularly severe problem, but one issue is that because of the
request/response nature of the v2 protocol, it will happily read an
unbounded number of packets, adding each one to a string list (without
regard to whether they are objects we know about, duplicates, etc).
This may be something we want to improve in the long run, but in the
short term it makes sense to disable the feature entirely. We'll add a
config option as an escape hatch for anybody who wants to develop the
feature further.
A more gentle option would be to add the config option to let people
disable it manually, but leave it enabled by default. But given that
there's no client side support, that seems like the wrong balance with
security.
Disabling by default will slow adoption a bit once client-side support
does become available (there were some patches[1] in 2022, but nothing
got merged and there's been nothing since). But clients have to deal
with older servers that do not understand the option anyway (and the
capability system handles that), so it will just be a matter of servers
flipping their config at that point (and hopefully once any unbounded
allocations have been addressed).
[jk: this is a patch that GitHub has been running for several years, but
rebased forward and with a new commit message for upstream]
[1] https://lore.kernel.org/git/20220208231911.725273-1-calvinwan@google.com/
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-02-29 06:38:58 +08:00
|
|
|
.advertise = object_info_advertise,
|
2021-08-05 09:25:37 +08:00
|
|
|
.command = cap_object_info,
|
|
|
|
},
|
2022-12-22 23:14:07 +08:00
|
|
|
{
|
|
|
|
.name = "bundle-uri",
|
|
|
|
.advertise = bundle_uri_advertise,
|
|
|
|
.command = bundle_uri_command,
|
|
|
|
},
|
2018-03-16 01:31:19 +08:00
|
|
|
};
|
|
|
|
|
serve.[ch]: remove "serve_options", split up --advertise-refs code
The "advertise capabilities" mode of serve.c added in
ed10cb952d3 (serve: introduce git-serve, 2018-03-15) is only used by
the http-backend.c to call {upload,receive}-pack with the
--advertise-refs parameter. See 42526b478e3 (Add stateless RPC options
to upload-pack, receive-pack, 2009-10-30).
Let's just make cmd_upload_pack() take the two (v2) or three (v2)
parameters the the v2/v1 servicing functions need directly, and pass
those in via the function signature. The logic of whether daemon mode
is implied by the timeout belongs in the v1 function (only used
there).
Once we split up the "advertise v2 refs" from "serve v2 request" it
becomes clear that v2 never cared about those in combination. The only
time it mattered was for v1 to emit its ref advertisement, in that
case we wanted to emit the smart-http-only "no-done" capability.
Since we only do that in the --advertise-refs codepath let's just have
it set "do_done" itself in v1's upload_pack() just before send_ref(),
at that point --advertise-refs and --stateless-rpc in combination are
redundant (the only user is get_info_refs() in http-backend.c), so we
can just pass in --advertise-refs only.
Since we need to touch all the serve() and advertise_capabilities()
codepaths let's rename them to less clever and obvious names, it's
been suggested numerous times, the latest of which is [1]'s suggestion
for protocol_v2_serve_loop(). Let's go with that.
1. https://lore.kernel.org/git/CAFQ2z_NyGb8rju5CKzmo6KhZXD0Dp21u-BbyCb2aNxLEoSPRJw@mail.gmail.com/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-05 09:25:42 +08:00
|
|
|
void protocol_v2_advertise_capabilities(void)
|
2018-03-16 01:31:19 +08:00
|
|
|
{
|
|
|
|
struct strbuf capability = STRBUF_INIT;
|
|
|
|
struct strbuf value = STRBUF_INIT;
|
|
|
|
int i;
|
|
|
|
|
2021-08-05 09:25:40 +08:00
|
|
|
/* serve by default supports v2 */
|
|
|
|
packet_write_fmt(1, "version 2\n");
|
|
|
|
|
2018-03-16 01:31:19 +08:00
|
|
|
for (i = 0; i < ARRAY_SIZE(capabilities); i++) {
|
|
|
|
struct protocol_capability *c = &capabilities[i];
|
|
|
|
|
|
|
|
if (c->advertise(the_repository, &value)) {
|
|
|
|
strbuf_addstr(&capability, c->name);
|
|
|
|
|
|
|
|
if (value.len) {
|
|
|
|
strbuf_addch(&capability, '=');
|
|
|
|
strbuf_addbuf(&capability, &value);
|
|
|
|
}
|
|
|
|
|
|
|
|
strbuf_addch(&capability, '\n');
|
|
|
|
packet_write(1, capability.buf, capability.len);
|
|
|
|
}
|
|
|
|
|
|
|
|
strbuf_reset(&capability);
|
|
|
|
strbuf_reset(&value);
|
|
|
|
}
|
|
|
|
|
|
|
|
packet_flush(1);
|
|
|
|
strbuf_release(&capability);
|
|
|
|
strbuf_release(&value);
|
|
|
|
}
|
|
|
|
|
2021-09-14 23:30:50 +08:00
|
|
|
static struct protocol_capability *get_capability(const char *key, const char **value)
|
2018-03-16 01:31:19 +08:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (!key)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(capabilities); i++) {
|
|
|
|
struct protocol_capability *c = &capabilities[i];
|
|
|
|
const char *out;
|
2021-09-14 23:30:50 +08:00
|
|
|
if (!skip_prefix(key, c->name, &out))
|
|
|
|
continue;
|
|
|
|
if (!*out) {
|
|
|
|
*value = NULL;
|
2018-03-16 01:31:19 +08:00
|
|
|
return c;
|
2021-09-14 23:30:50 +08:00
|
|
|
}
|
|
|
|
if (*out++ == '=') {
|
|
|
|
*value = out;
|
|
|
|
return c;
|
|
|
|
}
|
2018-03-16 01:31:19 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2021-09-14 23:31:07 +08:00
|
|
|
static int receive_client_capability(const char *key)
|
2018-03-16 01:31:19 +08:00
|
|
|
{
|
2021-09-14 23:30:50 +08:00
|
|
|
const char *value;
|
|
|
|
const struct protocol_capability *c = get_capability(key, &value);
|
2018-03-16 01:31:19 +08:00
|
|
|
|
serve: reject commands used as capabilities
Our table of v2 "capabilities" contains everything we might tell the
client we support. But there are differences in how we expect the client
to respond. Some of the entries are true capabilities (i.e., we expect
the client to say "yes, I support this"), and some are ones we expect
them to send as commands (with "command=ls-refs" or similar).
When we receive a capability used as a command, we complain about that.
But when we receive a command used as a capability (e.g., just "ls-refs"
in a pkt-line by itself), we silently ignore it.
This isn't really hurting anything (clients shouldn't send it, and we'll
ignore it), but we can tighten up the protocol to match what we expect
to happen.
There are two new tests here. The first one checks a capability used as
a command, which already passes. The second tests a command as a
capability, which this patch fixes.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-16 02:36:36 +08:00
|
|
|
if (!c || c->command || !c->advertise(the_repository, NULL))
|
2021-09-14 23:31:07 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (c->receive)
|
|
|
|
c->receive(the_repository, value);
|
|
|
|
return 1;
|
2018-03-16 01:31:19 +08:00
|
|
|
}
|
|
|
|
|
2021-09-14 23:30:20 +08:00
|
|
|
static int parse_command(const char *key, struct protocol_capability **command)
|
2018-03-16 01:31:19 +08:00
|
|
|
{
|
|
|
|
const char *out;
|
|
|
|
|
|
|
|
if (skip_prefix(key, "command=", &out)) {
|
2021-09-14 23:30:50 +08:00
|
|
|
const char *value;
|
|
|
|
struct protocol_capability *cmd = get_capability(out, &value);
|
2018-03-16 01:31:19 +08:00
|
|
|
|
|
|
|
if (*command)
|
|
|
|
die("command '%s' requested after already requesting command '%s'",
|
|
|
|
out, (*command)->name);
|
serve: reject bogus v2 "command=ls-refs=foo"
When we see a line from the client like "command=ls-refs", we parse
everything after the equals sign as a capability, which we check against
our capabilities table. If we don't recognize the command (e.g.,
"command=foo"), we'll reject it.
But in parse_command(), we use the same get_capability() parser for
parsing non-command lines. So if we see "command=ls-refs=foo", we will
feed "ls-refs=foo" to get_capability(), which will say "OK, that's
ls-refs, with value 'foo'". But then we simply ignore the value
entirely.
The client is violating the spec here, which says:
command = PKT-LINE("command=" key LF)
key = 1*(ALPHA | DIGIT | "-_")
I.e., the key is not even allowed to have an equals sign in it. Whereas
a real non-command capability does allow a value:
capability = PKT-LINE(key[=value] LF)
So by reusing the same get_capability() parser, we are mixing up the
"key" and "capability" tokens. However, since that parser tells us
whether it saw an "=", we can still use it; we just need to reject any
input that produces a non-NULL value field.
The current behavior isn't really hurting anything (the client should
never send such a request, and if it does, we just ignore the "value"
part). But since it does violate the spec, let's tighten it up to
prevent any surprising behavior.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-16 02:36:33 +08:00
|
|
|
if (!cmd || !cmd->advertise(the_repository, NULL) || !cmd->command || value)
|
2018-03-16 01:31:19 +08:00
|
|
|
die("invalid command '%s'", out);
|
|
|
|
|
|
|
|
*command = cmd;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
enum request_state {
|
|
|
|
PROCESS_REQUEST_KEYS,
|
|
|
|
PROCESS_REQUEST_DONE,
|
|
|
|
};
|
|
|
|
|
|
|
|
static int process_request(void)
|
|
|
|
{
|
|
|
|
enum request_state state = PROCESS_REQUEST_KEYS;
|
|
|
|
struct packet_reader reader;
|
2021-09-16 02:35:29 +08:00
|
|
|
int seen_capability_or_command = 0;
|
2018-03-16 01:31:19 +08:00
|
|
|
struct protocol_capability *command = NULL;
|
|
|
|
|
|
|
|
packet_reader_init(&reader, 0, NULL, 0,
|
|
|
|
PACKET_READ_CHOMP_NEWLINE |
|
pack-protocol.txt: accept error packets in any context
In the Git pack protocol definition, an error packet may appear only in
a certain context. However, servers can face a runtime error (e.g. I/O
error) at an arbitrary timing. This patch changes the protocol to allow
an error packet to be sent instead of any packet.
Without this protocol spec change, when a server cannot process a
request, there's no way to tell that to a client. Since the server
cannot produce a valid response, it would be forced to cut a connection
without telling why. With this protocol spec change, the server can be
more gentle in this situation. An old client may see these error packets
as an unexpected packet, but this is not worse than having an unexpected
EOF.
Following this protocol spec change, the error packet handling code is
moved to pkt-line.c. Implementation wise, this implementation uses
pkt-line to communicate with a subprocess. Since this is not a part of
Git protocol, it's possible that a packet that is not supposed to be an
error packet is mistakenly parsed as an error packet. This error packet
handling is enabled only for the Git pack protocol parsing code
considering this.
Signed-off-by: Masaya Suzuki <masayasuzuki@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-30 05:19:15 +08:00
|
|
|
PACKET_READ_GENTLE_ON_EOF |
|
|
|
|
PACKET_READ_DIE_ON_ERR_PACKET);
|
2018-03-16 01:31:19 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Check to see if the client closed their end before sending another
|
|
|
|
* request. If so we can terminate the connection.
|
|
|
|
*/
|
|
|
|
if (packet_reader_peek(&reader) == PACKET_READ_EOF)
|
|
|
|
return 1;
|
pack-protocol.txt: accept error packets in any context
In the Git pack protocol definition, an error packet may appear only in
a certain context. However, servers can face a runtime error (e.g. I/O
error) at an arbitrary timing. This patch changes the protocol to allow
an error packet to be sent instead of any packet.
Without this protocol spec change, when a server cannot process a
request, there's no way to tell that to a client. Since the server
cannot produce a valid response, it would be forced to cut a connection
without telling why. With this protocol spec change, the server can be
more gentle in this situation. An old client may see these error packets
as an unexpected packet, but this is not worse than having an unexpected
EOF.
Following this protocol spec change, the error packet handling code is
moved to pkt-line.c. Implementation wise, this implementation uses
pkt-line to communicate with a subprocess. Since this is not a part of
Git protocol, it's possible that a packet that is not supposed to be an
error packet is mistakenly parsed as an error packet. This error packet
handling is enabled only for the Git pack protocol parsing code
considering this.
Signed-off-by: Masaya Suzuki <masayasuzuki@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-30 05:19:15 +08:00
|
|
|
reader.options &= ~PACKET_READ_GENTLE_ON_EOF;
|
2018-03-16 01:31:19 +08:00
|
|
|
|
|
|
|
while (state != PROCESS_REQUEST_DONE) {
|
|
|
|
switch (packet_reader_peek(&reader)) {
|
|
|
|
case PACKET_READ_EOF:
|
|
|
|
BUG("Should have already died when seeing EOF");
|
|
|
|
case PACKET_READ_NORMAL:
|
2021-09-14 23:30:20 +08:00
|
|
|
if (parse_command(reader.line, &command) ||
|
2021-09-14 23:31:07 +08:00
|
|
|
receive_client_capability(reader.line))
|
2021-09-16 02:35:29 +08:00
|
|
|
seen_capability_or_command = 1;
|
2018-03-16 01:31:19 +08:00
|
|
|
else
|
|
|
|
die("unknown capability '%s'", reader.line);
|
|
|
|
|
|
|
|
/* Consume the peeked line */
|
|
|
|
packet_reader_read(&reader);
|
|
|
|
break;
|
|
|
|
case PACKET_READ_FLUSH:
|
|
|
|
/*
|
|
|
|
* If no command and no keys were given then the client
|
|
|
|
* wanted to terminate the connection.
|
|
|
|
*/
|
2021-09-16 02:35:29 +08:00
|
|
|
if (!seen_capability_or_command)
|
2018-03-16 01:31:19 +08:00
|
|
|
return 1;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The flush packet isn't consume here like it is in
|
|
|
|
* the other parts of this switch statement. This is
|
|
|
|
* so that the command can read the flush packet and
|
|
|
|
* see the end of the request in the same way it would
|
|
|
|
* if command specific arguments were provided after a
|
|
|
|
* delim packet.
|
|
|
|
*/
|
|
|
|
state = PROCESS_REQUEST_DONE;
|
|
|
|
break;
|
|
|
|
case PACKET_READ_DELIM:
|
|
|
|
/* Consume the peeked line */
|
|
|
|
packet_reader_read(&reader);
|
|
|
|
|
|
|
|
state = PROCESS_REQUEST_DONE;
|
|
|
|
break;
|
2020-05-19 18:53:59 +08:00
|
|
|
case PACKET_READ_RESPONSE_END:
|
2021-07-09 10:27:22 +08:00
|
|
|
BUG("unexpected response end packet");
|
2018-03-16 01:31:19 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!command)
|
|
|
|
die("no command requested");
|
|
|
|
|
2021-09-15 07:51:27 +08:00
|
|
|
if (client_hash_algo != hash_algo_by_ptr(the_repository->hash_algo))
|
2024-09-05 16:51:49 +08:00
|
|
|
die("mismatched object format: server %s; client %s",
|
2021-09-15 07:51:27 +08:00
|
|
|
the_repository->hash_algo->name,
|
|
|
|
hash_algos[client_hash_algo].name);
|
2020-05-26 03:59:17 +08:00
|
|
|
|
2021-08-05 09:25:38 +08:00
|
|
|
command->command(the_repository, &reader);
|
2018-03-16 01:31:19 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
serve.[ch]: remove "serve_options", split up --advertise-refs code
The "advertise capabilities" mode of serve.c added in
ed10cb952d3 (serve: introduce git-serve, 2018-03-15) is only used by
the http-backend.c to call {upload,receive}-pack with the
--advertise-refs parameter. See 42526b478e3 (Add stateless RPC options
to upload-pack, receive-pack, 2009-10-30).
Let's just make cmd_upload_pack() take the two (v2) or three (v2)
parameters the the v2/v1 servicing functions need directly, and pass
those in via the function signature. The logic of whether daemon mode
is implied by the timeout belongs in the v1 function (only used
there).
Once we split up the "advertise v2 refs" from "serve v2 request" it
becomes clear that v2 never cared about those in combination. The only
time it mattered was for v1 to emit its ref advertisement, in that
case we wanted to emit the smart-http-only "no-done" capability.
Since we only do that in the --advertise-refs codepath let's just have
it set "do_done" itself in v1's upload_pack() just before send_ref(),
at that point --advertise-refs and --stateless-rpc in combination are
redundant (the only user is get_info_refs() in http-backend.c), so we
can just pass in --advertise-refs only.
Since we need to touch all the serve() and advertise_capabilities()
codepaths let's rename them to less clever and obvious names, it's
been suggested numerous times, the latest of which is [1]'s suggestion
for protocol_v2_serve_loop(). Let's go with that.
1. https://lore.kernel.org/git/CAFQ2z_NyGb8rju5CKzmo6KhZXD0Dp21u-BbyCb2aNxLEoSPRJw@mail.gmail.com/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-05 09:25:42 +08:00
|
|
|
void protocol_v2_serve_loop(int stateless_rpc)
|
2018-03-16 01:31:19 +08:00
|
|
|
{
|
serve.[ch]: remove "serve_options", split up --advertise-refs code
The "advertise capabilities" mode of serve.c added in
ed10cb952d3 (serve: introduce git-serve, 2018-03-15) is only used by
the http-backend.c to call {upload,receive}-pack with the
--advertise-refs parameter. See 42526b478e3 (Add stateless RPC options
to upload-pack, receive-pack, 2009-10-30).
Let's just make cmd_upload_pack() take the two (v2) or three (v2)
parameters the the v2/v1 servicing functions need directly, and pass
those in via the function signature. The logic of whether daemon mode
is implied by the timeout belongs in the v1 function (only used
there).
Once we split up the "advertise v2 refs" from "serve v2 request" it
becomes clear that v2 never cared about those in combination. The only
time it mattered was for v1 to emit its ref advertisement, in that
case we wanted to emit the smart-http-only "no-done" capability.
Since we only do that in the --advertise-refs codepath let's just have
it set "do_done" itself in v1's upload_pack() just before send_ref(),
at that point --advertise-refs and --stateless-rpc in combination are
redundant (the only user is get_info_refs() in http-backend.c), so we
can just pass in --advertise-refs only.
Since we need to touch all the serve() and advertise_capabilities()
codepaths let's rename them to less clever and obvious names, it's
been suggested numerous times, the latest of which is [1]'s suggestion
for protocol_v2_serve_loop(). Let's go with that.
1. https://lore.kernel.org/git/CAFQ2z_NyGb8rju5CKzmo6KhZXD0Dp21u-BbyCb2aNxLEoSPRJw@mail.gmail.com/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-05 09:25:42 +08:00
|
|
|
if (!stateless_rpc)
|
|
|
|
protocol_v2_advertise_capabilities();
|
2018-03-16 01:31:19 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If stateless-rpc was requested then exit after
|
|
|
|
* a single request/response exchange
|
|
|
|
*/
|
serve.[ch]: remove "serve_options", split up --advertise-refs code
The "advertise capabilities" mode of serve.c added in
ed10cb952d3 (serve: introduce git-serve, 2018-03-15) is only used by
the http-backend.c to call {upload,receive}-pack with the
--advertise-refs parameter. See 42526b478e3 (Add stateless RPC options
to upload-pack, receive-pack, 2009-10-30).
Let's just make cmd_upload_pack() take the two (v2) or three (v2)
parameters the the v2/v1 servicing functions need directly, and pass
those in via the function signature. The logic of whether daemon mode
is implied by the timeout belongs in the v1 function (only used
there).
Once we split up the "advertise v2 refs" from "serve v2 request" it
becomes clear that v2 never cared about those in combination. The only
time it mattered was for v1 to emit its ref advertisement, in that
case we wanted to emit the smart-http-only "no-done" capability.
Since we only do that in the --advertise-refs codepath let's just have
it set "do_done" itself in v1's upload_pack() just before send_ref(),
at that point --advertise-refs and --stateless-rpc in combination are
redundant (the only user is get_info_refs() in http-backend.c), so we
can just pass in --advertise-refs only.
Since we need to touch all the serve() and advertise_capabilities()
codepaths let's rename them to less clever and obvious names, it's
been suggested numerous times, the latest of which is [1]'s suggestion
for protocol_v2_serve_loop(). Let's go with that.
1. https://lore.kernel.org/git/CAFQ2z_NyGb8rju5CKzmo6KhZXD0Dp21u-BbyCb2aNxLEoSPRJw@mail.gmail.com/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-05 09:25:42 +08:00
|
|
|
if (stateless_rpc) {
|
2018-03-16 01:31:19 +08:00
|
|
|
process_request();
|
|
|
|
} else {
|
|
|
|
for (;;)
|
|
|
|
if (process_request())
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|