2011-04-03 07:06:54 +00:00
|
|
|
#include "builtin.h"
|
2023-03-21 06:25:58 +00:00
|
|
|
#include "abspath.h"
|
2018-03-23 17:45:21 +00:00
|
|
|
#include "repository.h"
|
2017-06-14 18:07:36 +00:00
|
|
|
#include "config.h"
|
2023-03-21 06:26:03 +00:00
|
|
|
#include "environment.h"
|
2023-03-21 06:25:54 +00:00
|
|
|
#include "gettext.h"
|
2023-02-24 00:09:27 +00:00
|
|
|
#include "hex.h"
|
2014-10-01 10:28:42 +00:00
|
|
|
#include "lockfile.h"
|
2006-11-01 22:06:21 +00:00
|
|
|
#include "pack.h"
|
2005-07-03 03:23:36 +00:00
|
|
|
#include "refs.h"
|
2005-06-30 03:50:15 +00:00
|
|
|
#include "pkt-line.h"
|
2010-02-05 20:57:41 +00:00
|
|
|
#include "sideband.h"
|
2005-07-31 19:17:43 +00:00
|
|
|
#include "run-command.h"
|
2021-09-26 19:03:26 +00:00
|
|
|
#include "hook.h"
|
2018-04-10 21:26:18 +00:00
|
|
|
#include "exec-cmd.h"
|
2006-09-20 23:07:54 +00:00
|
|
|
#include "commit.h"
|
|
|
|
#include "object.h"
|
push: receiver end advertises refs from alternate repositories
Earlier, when pushing into a repository that borrows from alternate object
stores, we followed the longstanding design decision not to trust refs in
the alternate repository that houses the object store we are borrowing
from. If your public repository is borrowing from Linus's public
repository, you pushed into it long time ago, and now when you try to push
your updated history that is in sync with more recent history from Linus,
you will end up sending not just your own development, but also the
changes you acquired through Linus's tree, even though the objects needed
for the latter already exists at the receiving end. This is because the
receiving end does not advertise that the objects only reachable from the
borrowed repository (i.e. Linus's) are already available there.
This solves the issue by making the receiving end advertise refs from
borrowed repositories. They are not sent with their true names but with a
phoney name ".have" to make sure that the old senders will safely ignore
them (otherwise, the old senders will misbehave, trying to push matching
refs, and mirror push that deletes refs that only exist at the receiving
end).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-09 08:27:10 +00:00
|
|
|
#include "remote.h"
|
2013-07-08 20:56:53 +00:00
|
|
|
#include "connect.h"
|
2010-04-19 22:19:18 +00:00
|
|
|
#include "string-list.h"
|
2020-03-30 14:03:46 +00:00
|
|
|
#include "oid-array.h"
|
2011-09-02 23:52:08 +00:00
|
|
|
#include "connected.h"
|
2020-07-28 20:23:39 +00:00
|
|
|
#include "strvec.h"
|
2012-08-03 16:19:16 +00:00
|
|
|
#include "version.h"
|
2014-08-14 22:59:21 +00:00
|
|
|
#include "tag.h"
|
|
|
|
#include "gpg-interface.h"
|
receive-pack: allow hooks to ignore its standard input stream
The pre-receive and post-receive hooks were designed to be an
improvement over old style update and post-update hooks, which take
the update information on their command line and are limited by the
command line length limit. The same information is fed from the
standard input to pre/post-receive hooks instead to lift this
limitation. It has been mandatory for these new style hooks to
consume the update information fully from the standard input stream.
Otherwise, they would risk killing the receive-pack process via
SIGPIPE.
If a hook does not want to look at all the information, it is easy
to send its standard input to /dev/null (perhaps a niche use of hook
might need to know only the fact that a push was made, without
having to know what objects have been pushed to update which refs),
and this has already been done by existing hooks that are written
carefully.
However, because there is no good way to consistently fail hooks
that do not consume the input fully (a small push may result in a
short update record that may fit within the pipe buffer, to which
the receive-pack process may manage to write before the hook has a
chance to exit without reading anything, which will not result in a
death-by-SIGPIPE of receive-pack), it can lead to a hard to diagnose
"once in a blue moon" phantom failure.
Lift this "hooks must consume their input fully" mandate. A mandate
that is not enforced strictly is not helping us to catch mistakes in
hooks. If a hook has a good reason to decide the outcome of its
operation without reading the information we feed it, let it do so
as it pleases.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-12 22:48:07 +00:00
|
|
|
#include "sigchain.h"
|
2015-06-22 15:25:31 +00:00
|
|
|
#include "fsck.h"
|
2016-10-03 20:49:14 +00:00
|
|
|
#include "tmp-objdir.h"
|
receive-pack: use oidset to de-duplicate .have lines
If you have an alternate object store with a very large
number of refs, the peak memory usage of the sha1_array can
grow high, even if most of them are duplicates that end up
not being printed at all.
The similar for_each_alternate_ref() code-paths in
fetch-pack solve this by using flags in "struct object" to
de-duplicate (and so are relying on obj_hash at the core).
But we don't have a "struct object" at all in this case. We
could call lookup_unknown_object() to get one, but if our
goal is reducing memory footprint, it's not great:
- an unknown object is as large as the largest object type
(a commit), which is bigger than an oidset entry
- we can free the memory after our ref advertisement, but
"struct object" entries persist forever (and the
receive-pack may hang around for a long time, as the
bottleneck is often client upload bandwidth).
So let's use an oidset. Note that unlike a sha1-array it
doesn't sort the output as a side effect. However, our
output is at least stable, because for_each_alternate_ref()
will give us the sha1s in ref-sorted order.
In one particularly pathological case with an alternate that
has 60,000 unique refs out of 80 million total, this reduced
the peak heap usage of "git receive-pack . </dev/null" from
13GB to 14MB.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08 20:53:10 +00:00
|
|
|
#include "oidset.h"
|
2017-08-18 22:20:21 +00:00
|
|
|
#include "packfile.h"
|
2023-04-11 07:41:49 +00:00
|
|
|
#include "object-name.h"
|
2023-05-16 06:34:06 +00:00
|
|
|
#include "object-store-ll.h"
|
2023-05-16 06:33:59 +00:00
|
|
|
#include "path.h"
|
2017-10-16 17:55:26 +00:00
|
|
|
#include "protocol.h"
|
2018-07-20 16:33:04 +00:00
|
|
|
#include "commit-reach.h"
|
2023-04-22 20:17:11 +00:00
|
|
|
#include "server-info.h"
|
2023-04-11 03:00:38 +00:00
|
|
|
#include "trace.h"
|
|
|
|
#include "trace2.h"
|
receive.denyCurrentBranch: respect all worktrees
The receive.denyCurrentBranch config option controls what happens if
you push to a branch that is checked out into a non-bare repository.
By default, it rejects it. It can be disabled via `ignore` or `warn`.
Another yet trickier option is `updateInstead`.
However, this setting was forgotten when the git worktree command was
introduced: only the main worktree's current branch is respected.
With this change, all worktrees are respected.
That change also leads to revealing another bug,
i.e. `receive.denyCurrentBranch = true` was ignored when pushing into a
non-bare repository's unborn current branch using ref namespaces. As
`is_ref_checked_out()` returns 0 which means `receive-pack` does not get
into conditional statement to switch `deny_current_branch` accordingly
(ignore, warn, refuse, unconfigured, updateInstead).
receive.denyCurrentBranch uses the function `refs_resolve_ref_unsafe()`
(called via `resolve_refdup()`) to resolve the symbolic ref HEAD, but
that function fails when HEAD does not point at a valid commit.
As we replace the call to `refs_resolve_ref_unsafe()` with
`find_shared_symref()`, which has no problem finding the worktree for a
given branch even if it is unborn yet, this bug is fixed at the same
time: receive.denyCurrentBranch now also handles worktrees with unborn
branches as intended even while using ref namespaces.
Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Hariom Verma <hariom18599@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-23 18:57:10 +00:00
|
|
|
#include "worktree.h"
|
2020-04-30 19:48:50 +00:00
|
|
|
#include "shallow.h"
|
treewide: include parse-options.h in source files
The builtins 'ls-remote', 'pack-objects', 'receive-pack', 'reflog' and
'send-pack' use parse_options(), but their source files don't directly
include 'parse-options.h'. Furthermore, the source files
'diagnose.c', 'list-objects-filter-options.c', 'remote.c' and
'send-pack.c' define option parsing callback functions, while
'revision.c' defines an option parsing helper function, and thus need
access to various fields in 'struct option' and 'struct
parse_opt_ctx_t', but they don't directly include 'parse-options.h'
either. They all can still be built, of course, because they include
one of the header files that does include 'parse-options.h' (though
unnecessarily, see the next commit).
Add those missing includes to these files, as our general rule is that
"a C file must directly include the header files that declare the
functions and the types it uses".
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Reviewed-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-19 16:27:11 +00:00
|
|
|
#include "parse-options.h"
|
2023-03-21 06:26:01 +00:00
|
|
|
#include "wrapper.h"
|
2005-06-30 00:52:11 +00:00
|
|
|
|
2016-03-01 20:21:01 +00:00
|
|
|
static const char * const receive_pack_usage[] = {
|
|
|
|
N_("git receive-pack <git-dir>"),
|
|
|
|
NULL
|
|
|
|
};
|
2005-06-30 00:52:11 +00:00
|
|
|
|
2008-11-09 01:49:27 +00:00
|
|
|
enum deny_action {
|
2009-02-01 01:34:05 +00:00
|
|
|
DENY_UNCONFIGURED,
|
2008-11-09 01:49:27 +00:00
|
|
|
DENY_IGNORE,
|
|
|
|
DENY_WARN,
|
2014-11-26 22:44:16 +00:00
|
|
|
DENY_REFUSE,
|
|
|
|
DENY_UPDATE_INSTEAD
|
2008-11-09 01:49:27 +00:00
|
|
|
};
|
|
|
|
|
2009-02-09 06:19:43 +00:00
|
|
|
static int deny_deletes;
|
|
|
|
static int deny_non_fast_forwards;
|
2009-02-01 01:34:05 +00:00
|
|
|
static enum deny_action deny_current_branch = DENY_UNCONFIGURED;
|
2009-02-09 06:31:21 +00:00
|
|
|
static enum deny_action deny_delete_current = DENY_UNCONFIGURED;
|
2011-09-04 19:37:45 +00:00
|
|
|
static int receive_fsck_objects = -1;
|
|
|
|
static int transfer_fsck_objects = -1;
|
2015-06-22 15:25:31 +00:00
|
|
|
static struct strbuf fsck_msg_types = STRBUF_INIT;
|
2007-01-25 01:02:15 +00:00
|
|
|
static int receive_unpack_limit = -1;
|
|
|
|
static int transfer_unpack_limit = -1;
|
2015-01-08 03:23:20 +00:00
|
|
|
static int advertise_atomic_push = 1;
|
2016-07-14 21:49:46 +00:00
|
|
|
static int advertise_push_options;
|
2020-11-11 23:29:28 +00:00
|
|
|
static int advertise_sid;
|
2006-12-07 04:01:00 +00:00
|
|
|
static int unpack_limit = 100;
|
2016-08-24 18:41:57 +00:00
|
|
|
static off_t max_input_size;
|
2006-08-15 17:23:48 +00:00
|
|
|
static int report_status;
|
2020-08-27 15:45:46 +00:00
|
|
|
static int report_status_v2;
|
2010-02-05 20:57:41 +00:00
|
|
|
static int use_sideband;
|
2015-01-08 03:23:19 +00:00
|
|
|
static int use_atomic;
|
2016-07-14 21:49:46 +00:00
|
|
|
static int use_push_options;
|
2012-01-08 21:06:20 +00:00
|
|
|
static int quiet;
|
2009-05-01 20:56:47 +00:00
|
|
|
static int prefer_ofs_delta = 1;
|
2009-10-20 21:56:40 +00:00
|
|
|
static int auto_update_server_info;
|
|
|
|
static int auto_gc = 1;
|
2016-03-01 20:21:01 +00:00
|
|
|
static int reject_thin;
|
signed push: allow stale nonce in stateless mode
When operating with the stateless RPC mode, we will receive a nonce
issued by another instance of us that advertised our capability and
refs some time ago. Update the logic to check received nonce to
detect this case, compute how much time has passed since the nonce
was issued and report the status with a new environment variable
GIT_PUSH_CERT_NONCE_SLOP to the hooks.
GIT_PUSH_CERT_NONCE_STATUS will report "SLOP" in such a case. The
hooks are free to decide how large a slop it is willing to accept.
Strictly speaking, the "nonce" is not really a "nonce" anymore in
the stateless RPC mode, as it will happily take any "nonce" issued
by it (which is protected by HMAC and its secret key) as long as it
is fresh enough. The degree of this security degradation, relative
to the native protocol, is about the same as the "we make sure that
the 'git push' decided to update our refs with new objects based on
the freshest observation of our refs by making sure the values they
claim the original value of the refs they ask us to update exactly
match the current state" security is loosened to accomodate the
stateless RPC mode in the existing code without this series, so
there is no need for those who are already using smart HTTP to push
to their repositories to be alarmed any more than they already are.
In addition, the server operator can set receive.certnonceslop
configuration variable to specify how stale a nonce can be (in
seconds). When this variable is set, and if the nonce received in
the certificate that passes the HMAC check was less than that many
seconds old, hooks are given "OK" in GIT_PUSH_CERT_NONCE_STATUS
(instead of "SLOP") and the received nonce value is given in
GIT_PUSH_CERT_NONCE, which makes it easier for a simple-minded
hook to check if the certificate we received is recent enough.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-05 17:46:04 +00:00
|
|
|
static int stateless_rpc;
|
|
|
|
static const char *service_dir;
|
2009-02-09 06:31:21 +00:00
|
|
|
static const char *head_name;
|
2011-12-13 14:17:48 +00:00
|
|
|
static void *head_name_to_free;
|
2010-02-05 20:57:40 +00:00
|
|
|
static int sent_capabilities;
|
2013-12-05 13:02:47 +00:00
|
|
|
static int shallow_update;
|
2013-12-05 13:02:44 +00:00
|
|
|
static const char *alt_shallow_file;
|
push: the beginning of "git push --signed"
While signed tags and commits assert that the objects thusly signed
came from you, who signed these objects, there is not a good way to
assert that you wanted to have a particular object at the tip of a
particular branch. My signing v2.0.1 tag only means I want to call
the version v2.0.1, and it does not mean I want to push it out to my
'master' branch---it is likely that I only want it in 'maint', so
the signature on the object alone is insufficient.
The only assurance to you that 'maint' points at what I wanted to
place there comes from your trust on the hosting site and my
authentication with it, which cannot easily audited later.
Introduce a mechanism that allows you to sign a "push certificate"
(for the lack of better name) every time you push, asserting that
what object you are pushing to update which ref that used to point
at what other object. Think of it as a cryptographic protection for
ref updates, similar to signed tags/commits but working on an
orthogonal axis.
The basic flow based on this mechanism goes like this:
1. You push out your work with "git push --signed".
2. The sending side learns where the remote refs are as usual,
together with what protocol extension the receiving end
supports. If the receiving end does not advertise the protocol
extension "push-cert", an attempt to "git push --signed" fails.
Otherwise, a text file, that looks like the following, is
prepared in core:
certificate version 0.1
pusher Junio C Hamano <gitster@pobox.com> 1315427886 -0700
7339ca65... 21580ecb... refs/heads/master
3793ac56... 12850bec... refs/heads/next
The file begins with a few header lines, which may grow as we
gain more experience. The 'pusher' header records the name of
the signer (the value of user.signingkey configuration variable,
falling back to GIT_COMMITTER_{NAME|EMAIL}) and the time of the
certificate generation. After the header, a blank line follows,
followed by a copy of the protocol message lines.
Each line shows the old and the new object name at the tip of
the ref this push tries to update, in the way identical to how
the underlying "git push" protocol exchange tells the ref
updates to the receiving end (by recording the "old" object
name, the push certificate also protects against replaying). It
is expected that new command packet types other than the
old-new-refname kind will be included in push certificate in the
same way as would appear in the plain vanilla command packets in
unsigned pushes.
The user then is asked to sign this push certificate using GPG,
formatted in a way similar to how signed tag objects are signed,
and the result is sent to the other side (i.e. receive-pack).
In the protocol exchange, this step comes immediately before the
sender tells what the result of the push should be, which in
turn comes before it sends the pack data.
3. When the receiving end sees a push certificate, the certificate
is written out as a blob. The pre-receive hook can learn about
the certificate by checking GIT_PUSH_CERT environment variable,
which, if present, tells the object name of this blob, and make
the decision to allow or reject this push. Additionally, the
post-receive hook can also look at the certificate, which may be
a good place to log all the received certificates for later
audits.
Because a push certificate carry the same information as the usual
command packets in the protocol exchange, we can omit the latter
when a push certificate is in use and reduce the protocol overhead.
This however is not included in this patch to make it easier to
review (in other words, the series at this step should never be
released without the remainder of the series, as it implements an
interim protocol that will be incompatible with the final one).
As such, the documentation update for the protocol is left out of
this step.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-12 18:17:07 +00:00
|
|
|
static struct strbuf push_cert = STRBUF_INIT;
|
2018-01-28 00:13:19 +00:00
|
|
|
static struct object_id push_cert_oid;
|
2014-08-14 22:59:21 +00:00
|
|
|
static struct signature_check sigcheck;
|
2014-08-21 23:45:30 +00:00
|
|
|
static const char *push_cert_nonce;
|
|
|
|
static const char *cert_nonce_seed;
|
2022-11-17 05:46:43 +00:00
|
|
|
static struct string_list hidden_refs = STRING_LIST_INIT_DUP;
|
2014-08-21 23:45:30 +00:00
|
|
|
|
|
|
|
static const char *NONCE_UNSOLICITED = "UNSOLICITED";
|
|
|
|
static const char *NONCE_BAD = "BAD";
|
|
|
|
static const char *NONCE_MISSING = "MISSING";
|
|
|
|
static const char *NONCE_OK = "OK";
|
signed push: allow stale nonce in stateless mode
When operating with the stateless RPC mode, we will receive a nonce
issued by another instance of us that advertised our capability and
refs some time ago. Update the logic to check received nonce to
detect this case, compute how much time has passed since the nonce
was issued and report the status with a new environment variable
GIT_PUSH_CERT_NONCE_SLOP to the hooks.
GIT_PUSH_CERT_NONCE_STATUS will report "SLOP" in such a case. The
hooks are free to decide how large a slop it is willing to accept.
Strictly speaking, the "nonce" is not really a "nonce" anymore in
the stateless RPC mode, as it will happily take any "nonce" issued
by it (which is protected by HMAC and its secret key) as long as it
is fresh enough. The degree of this security degradation, relative
to the native protocol, is about the same as the "we make sure that
the 'git push' decided to update our refs with new objects based on
the freshest observation of our refs by making sure the values they
claim the original value of the refs they ask us to update exactly
match the current state" security is loosened to accomodate the
stateless RPC mode in the existing code without this series, so
there is no need for those who are already using smart HTTP to push
to their repositories to be alarmed any more than they already are.
In addition, the server operator can set receive.certnonceslop
configuration variable to specify how stale a nonce can be (in
seconds). When this variable is set, and if the nonce received in
the certificate that passes the HMAC check was less than that many
seconds old, hooks are given "OK" in GIT_PUSH_CERT_NONCE_STATUS
(instead of "SLOP") and the received nonce value is given in
GIT_PUSH_CERT_NONCE, which makes it easier for a simple-minded
hook to check if the certificate we received is recent enough.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-05 17:46:04 +00:00
|
|
|
static const char *NONCE_SLOP = "SLOP";
|
2014-08-21 23:45:30 +00:00
|
|
|
static const char *nonce_status;
|
signed push: allow stale nonce in stateless mode
When operating with the stateless RPC mode, we will receive a nonce
issued by another instance of us that advertised our capability and
refs some time ago. Update the logic to check received nonce to
detect this case, compute how much time has passed since the nonce
was issued and report the status with a new environment variable
GIT_PUSH_CERT_NONCE_SLOP to the hooks.
GIT_PUSH_CERT_NONCE_STATUS will report "SLOP" in such a case. The
hooks are free to decide how large a slop it is willing to accept.
Strictly speaking, the "nonce" is not really a "nonce" anymore in
the stateless RPC mode, as it will happily take any "nonce" issued
by it (which is protected by HMAC and its secret key) as long as it
is fresh enough. The degree of this security degradation, relative
to the native protocol, is about the same as the "we make sure that
the 'git push' decided to update our refs with new objects based on
the freshest observation of our refs by making sure the values they
claim the original value of the refs they ask us to update exactly
match the current state" security is loosened to accomodate the
stateless RPC mode in the existing code without this series, so
there is no need for those who are already using smart HTTP to push
to their repositories to be alarmed any more than they already are.
In addition, the server operator can set receive.certnonceslop
configuration variable to specify how stale a nonce can be (in
seconds). When this variable is set, and if the nonce received in
the certificate that passes the HMAC check was less than that many
seconds old, hooks are given "OK" in GIT_PUSH_CERT_NONCE_STATUS
(instead of "SLOP") and the received nonce value is given in
GIT_PUSH_CERT_NONCE, which makes it easier for a simple-minded
hook to check if the certificate we received is recent enough.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-05 17:46:04 +00:00
|
|
|
static long nonce_stamp_slop;
|
2017-04-26 19:29:31 +00:00
|
|
|
static timestamp_t nonce_stamp_slop_limit;
|
2015-01-08 03:23:18 +00:00
|
|
|
static struct ref_transaction *transaction;
|
2005-12-26 07:18:37 +00:00
|
|
|
|
receive-pack: send keepalives during quiet periods
After a client has sent us the complete pack, we may spend
some time processing the data and running hooks. If the
client asked us to be quiet, receive-pack won't send any
progress data during the index-pack or connectivity-check
steps. And hooks may or may not produce their own progress
output. In these cases, the network connection is totally
silent from both ends.
Git itself doesn't care about this (it will wait forever),
but other parts of the system (e.g., firewalls,
load-balancers, etc) might hang up the connection. So we'd
like to send some sort of keepalive to let the network and
the client side know that we're still alive and processing.
We can use the same trick we did in 05e9515 (upload-pack:
send keepalive packets during pack computation, 2013-09-08).
Namely, we will send an empty sideband data packet every `N`
seconds that we do not relay any stderr data over the
sideband channel. As with 05e9515, this means that we won't
bother sending keepalives when there's actual progress data,
but will kick in when it has been disabled (or if there is a
lull in the progress data).
The concept is simple, but the details are subtle enough
that they need discussing here.
Before the client sends us the pack, we don't want to do any
keepalives. We'll have sent our ref advertisement, and we're
waiting for them to send us the pack (and tell us that they
support sidebands at all).
While we're receiving the pack from the client (or waiting
for it to start), there's no need for keepalives; it's up to
them to keep the connection active by sending data.
Moreover, it would be wrong for us to do so. When we are the
server in the smart-http protocol, we must treat our
connection as half-duplex. So any keepalives we send while
receiving the pack would potentially be buffered by the
webserver. Not only does this make them useless (since they
would not be delivered in a timely manner), but it could
actually cause a deadlock if we fill up the buffer with
keepalives. (It wouldn't be wrong to send keepalives in this
phase for a full-duplex connection like ssh; it's simply
pointless, as it is the client's responsibility to speak).
As soon as we've gotten all of the pack data, then the
client is waiting for us to speak, and we should start
keepalives immediately. From here until the end of the
connection, we send one any time we are not otherwise
sending data.
But there's a catch. Receive-pack doesn't know the moment
we've gotten all the data. It passes the descriptor to
index-pack, who reads all of the data, and then starts
resolving the deltas. We have to communicate that back.
To make this work, we instruct the sideband muxer to enable
keepalives in three phases:
1. In the beginning, not at all.
2. While reading from index-pack, wait for a signal
indicating end-of-input, and then start them.
3. Afterwards, always.
The signal from index-pack in phase 2 has to come over the
stderr channel which the muxer is reading. We can't use an
extra pipe because the portable run-command interface only
gives us stderr and stdout.
Stdout is already used to pass the .keep filename back to
receive-pack. We could also send a signal there, but then we
would find out about it in the main thread. And the
keepalive needs to be done by the async muxer thread (since
it's the one writing sideband data back to the client). And
we can't reliably signal the async thread from the main
thread, because the async code sometimes uses threads and
sometimes uses forked processes.
Therefore the signal must come over the stderr channel,
where it may be interspersed with other random
human-readable messages from index-pack. This patch makes
the signal a single NUL byte. This is easy to parse, should
not appear in any normal stderr output, and we don't have to
worry about any timing issues (like seeing half the signal
bytes in one read(), and half in a subsequent one).
This is a bit ugly, but it's simple to code and should work
reliably.
Another option would be to stop using an async thread for
muxing entirely, and just poll() both stderr and stdout of
index-pack from the main thread. This would work for
index-pack (because we aren't doing anything useful in the
main thread while it runs anyway). But it would make the
connectivity check and the hook muxers much more
complicated, as they need to simultaneously feed the
sub-programs while reading their stderr.
The index-pack phase is the only one that needs this
signaling, so it could simply behave differently than the
other two. That would mean having two separate
implementations of copy_to_sideband (and the keepalive
code), though. And it still doesn't get rid of the
signaling; it just means we can write a nicer message like
"END_OF_INPUT" or something on stdout, since we don't have
to worry about separating it from the stderr cruft.
One final note: this signaling trick is only done with
index-pack, not with unpack-objects. There's no point in
doing it for the latter, because by definition it only kicks
in for a small number of objects, where keepalives are not
as useful (and this conveniently lets us avoid duplicating
the implementation).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-15 10:43:47 +00:00
|
|
|
static enum {
|
|
|
|
KEEPALIVE_NEVER = 0,
|
|
|
|
KEEPALIVE_AFTER_NUL,
|
|
|
|
KEEPALIVE_ALWAYS
|
|
|
|
} use_keepalive;
|
|
|
|
static int keepalive_in_sec = 5;
|
|
|
|
|
2016-10-03 20:49:14 +00:00
|
|
|
static struct tmp_objdir *tmp_objdir;
|
|
|
|
|
2020-08-27 15:45:48 +00:00
|
|
|
static struct proc_receive_ref {
|
|
|
|
unsigned int want_add:1,
|
|
|
|
want_delete:1,
|
|
|
|
want_modify:1,
|
|
|
|
negative_ref:1;
|
|
|
|
char *ref_prefix;
|
|
|
|
struct proc_receive_ref *next;
|
|
|
|
} *proc_receive_ref;
|
|
|
|
|
|
|
|
static void proc_receive_ref_append(const char *prefix);
|
|
|
|
|
2008-11-09 01:49:27 +00:00
|
|
|
static enum deny_action parse_deny_action(const char *var, const char *value)
|
|
|
|
{
|
|
|
|
if (value) {
|
|
|
|
if (!strcasecmp(value, "ignore"))
|
|
|
|
return DENY_IGNORE;
|
|
|
|
if (!strcasecmp(value, "warn"))
|
|
|
|
return DENY_WARN;
|
|
|
|
if (!strcasecmp(value, "refuse"))
|
|
|
|
return DENY_REFUSE;
|
2014-11-26 22:44:16 +00:00
|
|
|
if (!strcasecmp(value, "updateinstead"))
|
|
|
|
return DENY_UPDATE_INSTEAD;
|
2008-11-09 01:49:27 +00:00
|
|
|
}
|
|
|
|
if (git_config_bool(var, value))
|
|
|
|
return DENY_REFUSE;
|
|
|
|
return DENY_IGNORE;
|
|
|
|
}
|
|
|
|
|
2008-05-14 17:46:53 +00:00
|
|
|
static int receive_pack_config(const char *var, const char *value, void *cb)
|
2006-10-30 22:35:18 +00:00
|
|
|
{
|
2022-11-17 05:46:43 +00:00
|
|
|
int status = parse_hide_refs_config(var, value, "receive", &hidden_refs);
|
upload/receive-pack: allow hiding ref hierarchies
A repository may have refs that are only used for its internal
bookkeeping purposes that should not be exposed to the others that
come over the network.
Teach upload-pack to omit some refs from its initial advertisement
by paying attention to the uploadpack.hiderefs multi-valued
configuration variable. Do the same to receive-pack via the
receive.hiderefs variable. As a convenient short-hand, allow using
transfer.hiderefs to set the value to both of these variables.
Any ref that is under the hierarchies listed on the value of these
variable is excluded from responses to requests made by "ls-remote",
"fetch", etc. (for upload-pack) and "push" (for receive-pack).
Because these hidden refs do not count as OUR_REF, an attempt to
fetch objects at the tip of them will be rejected, and because these
refs do not get advertised, "git push :" will not see local branches
that have the same name as them as "matching" ones to be sent.
An attempt to update/delete these hidden refs with an explicit
refspec, e.g. "git push origin :refs/hidden/22", is rejected. This
is not a new restriction. To the pusher, it would appear that there
is no such ref, so its push request will conclude with "Now that I
sent you all the data, it is time for you to update the refs. I saw
that the ref did not exist when I started pushing, and I want the
result to point at this commit". The receiving end will apply the
compare-and-swap rule to this request and rejects the push with
"Well, your update request conflicts with somebody else; I see there
is such a ref.", which is the right thing to do. Otherwise a push to
a hidden ref will always be "the last one wins", which is not a good
default.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-19 00:08:30 +00:00
|
|
|
|
|
|
|
if (status)
|
|
|
|
return status;
|
|
|
|
|
2008-11-01 14:42:16 +00:00
|
|
|
if (strcmp(var, "receive.denydeletes") == 0) {
|
|
|
|
deny_deletes = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-01-25 01:02:15 +00:00
|
|
|
if (strcmp(var, "receive.denynonfastforwards") == 0) {
|
2006-10-30 22:35:18 +00:00
|
|
|
deny_non_fast_forwards = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-01-25 01:02:15 +00:00
|
|
|
if (strcmp(var, "receive.unpacklimit") == 0) {
|
|
|
|
receive_unpack_limit = git_config_int(var, value);
|
2006-11-01 22:06:21 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-01-25 01:02:15 +00:00
|
|
|
if (strcmp(var, "transfer.unpacklimit") == 0) {
|
|
|
|
transfer_unpack_limit = git_config_int(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-06-22 15:27:18 +00:00
|
|
|
if (strcmp(var, "receive.fsck.skiplist") == 0) {
|
|
|
|
const char *path;
|
|
|
|
|
|
|
|
if (git_config_pathname(&path, var, value))
|
|
|
|
return 1;
|
|
|
|
strbuf_addf(&fsck_msg_types, "%cskiplist=%s",
|
|
|
|
fsck_msg_types.len ? ',' : '=', path);
|
|
|
|
free((char *)path);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-06-22 15:25:31 +00:00
|
|
|
if (skip_prefix(var, "receive.fsck.", &var)) {
|
|
|
|
if (is_valid_msg_type(var, value))
|
|
|
|
strbuf_addf(&fsck_msg_types, "%c%s=%s",
|
|
|
|
fsck_msg_types.len ? ',' : '=', var, value);
|
|
|
|
else
|
2021-12-01 22:15:41 +00:00
|
|
|
warning("skipping unknown msg id '%s'", var);
|
2015-06-22 15:25:31 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-02-25 21:46:13 +00:00
|
|
|
if (strcmp(var, "receive.fsckobjects") == 0) {
|
|
|
|
receive_fsck_objects = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-09-04 19:37:45 +00:00
|
|
|
if (strcmp(var, "transfer.fsckobjects") == 0) {
|
|
|
|
transfer_fsck_objects = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-11-09 01:49:27 +00:00
|
|
|
if (!strcmp(var, "receive.denycurrentbranch")) {
|
|
|
|
deny_current_branch = parse_deny_action(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-02-09 06:31:21 +00:00
|
|
|
if (strcmp(var, "receive.denydeletecurrent") == 0) {
|
|
|
|
deny_delete_current = parse_deny_action(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-05-01 20:56:47 +00:00
|
|
|
if (strcmp(var, "repack.usedeltabaseoffset") == 0) {
|
|
|
|
prefer_ofs_delta = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-10-20 21:56:40 +00:00
|
|
|
if (strcmp(var, "receive.updateserverinfo") == 0) {
|
|
|
|
auto_update_server_info = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (strcmp(var, "receive.autogc") == 0) {
|
|
|
|
auto_gc = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-12-05 13:02:47 +00:00
|
|
|
if (strcmp(var, "receive.shallowupdate") == 0) {
|
|
|
|
shallow_update = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-08-21 23:45:30 +00:00
|
|
|
if (strcmp(var, "receive.certnonceseed") == 0)
|
|
|
|
return git_config_string(&cert_nonce_seed, var, value);
|
push: the beginning of "git push --signed"
While signed tags and commits assert that the objects thusly signed
came from you, who signed these objects, there is not a good way to
assert that you wanted to have a particular object at the tip of a
particular branch. My signing v2.0.1 tag only means I want to call
the version v2.0.1, and it does not mean I want to push it out to my
'master' branch---it is likely that I only want it in 'maint', so
the signature on the object alone is insufficient.
The only assurance to you that 'maint' points at what I wanted to
place there comes from your trust on the hosting site and my
authentication with it, which cannot easily audited later.
Introduce a mechanism that allows you to sign a "push certificate"
(for the lack of better name) every time you push, asserting that
what object you are pushing to update which ref that used to point
at what other object. Think of it as a cryptographic protection for
ref updates, similar to signed tags/commits but working on an
orthogonal axis.
The basic flow based on this mechanism goes like this:
1. You push out your work with "git push --signed".
2. The sending side learns where the remote refs are as usual,
together with what protocol extension the receiving end
supports. If the receiving end does not advertise the protocol
extension "push-cert", an attempt to "git push --signed" fails.
Otherwise, a text file, that looks like the following, is
prepared in core:
certificate version 0.1
pusher Junio C Hamano <gitster@pobox.com> 1315427886 -0700
7339ca65... 21580ecb... refs/heads/master
3793ac56... 12850bec... refs/heads/next
The file begins with a few header lines, which may grow as we
gain more experience. The 'pusher' header records the name of
the signer (the value of user.signingkey configuration variable,
falling back to GIT_COMMITTER_{NAME|EMAIL}) and the time of the
certificate generation. After the header, a blank line follows,
followed by a copy of the protocol message lines.
Each line shows the old and the new object name at the tip of
the ref this push tries to update, in the way identical to how
the underlying "git push" protocol exchange tells the ref
updates to the receiving end (by recording the "old" object
name, the push certificate also protects against replaying). It
is expected that new command packet types other than the
old-new-refname kind will be included in push certificate in the
same way as would appear in the plain vanilla command packets in
unsigned pushes.
The user then is asked to sign this push certificate using GPG,
formatted in a way similar to how signed tag objects are signed,
and the result is sent to the other side (i.e. receive-pack).
In the protocol exchange, this step comes immediately before the
sender tells what the result of the push should be, which in
turn comes before it sends the pack data.
3. When the receiving end sees a push certificate, the certificate
is written out as a blob. The pre-receive hook can learn about
the certificate by checking GIT_PUSH_CERT environment variable,
which, if present, tells the object name of this blob, and make
the decision to allow or reject this push. Additionally, the
post-receive hook can also look at the certificate, which may be
a good place to log all the received certificates for later
audits.
Because a push certificate carry the same information as the usual
command packets in the protocol exchange, we can omit the latter
when a push certificate is in use and reduce the protocol overhead.
This however is not included in this patch to make it easier to
review (in other words, the series at this step should never be
released without the remainder of the series, as it implements an
interim protocol that will be incompatible with the final one).
As such, the documentation update for the protocol is left out of
this step.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-12 18:17:07 +00:00
|
|
|
|
signed push: allow stale nonce in stateless mode
When operating with the stateless RPC mode, we will receive a nonce
issued by another instance of us that advertised our capability and
refs some time ago. Update the logic to check received nonce to
detect this case, compute how much time has passed since the nonce
was issued and report the status with a new environment variable
GIT_PUSH_CERT_NONCE_SLOP to the hooks.
GIT_PUSH_CERT_NONCE_STATUS will report "SLOP" in such a case. The
hooks are free to decide how large a slop it is willing to accept.
Strictly speaking, the "nonce" is not really a "nonce" anymore in
the stateless RPC mode, as it will happily take any "nonce" issued
by it (which is protected by HMAC and its secret key) as long as it
is fresh enough. The degree of this security degradation, relative
to the native protocol, is about the same as the "we make sure that
the 'git push' decided to update our refs with new objects based on
the freshest observation of our refs by making sure the values they
claim the original value of the refs they ask us to update exactly
match the current state" security is loosened to accomodate the
stateless RPC mode in the existing code without this series, so
there is no need for those who are already using smart HTTP to push
to their repositories to be alarmed any more than they already are.
In addition, the server operator can set receive.certnonceslop
configuration variable to specify how stale a nonce can be (in
seconds). When this variable is set, and if the nonce received in
the certificate that passes the HMAC check was less than that many
seconds old, hooks are given "OK" in GIT_PUSH_CERT_NONCE_STATUS
(instead of "SLOP") and the received nonce value is given in
GIT_PUSH_CERT_NONCE, which makes it easier for a simple-minded
hook to check if the certificate we received is recent enough.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-05 17:46:04 +00:00
|
|
|
if (strcmp(var, "receive.certnonceslop") == 0) {
|
|
|
|
nonce_stamp_slop_limit = git_config_ulong(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-01-08 03:23:20 +00:00
|
|
|
if (strcmp(var, "receive.advertiseatomic") == 0) {
|
|
|
|
advertise_atomic_push = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-07-14 21:49:46 +00:00
|
|
|
if (strcmp(var, "receive.advertisepushoptions") == 0) {
|
|
|
|
advertise_push_options = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
receive-pack: send keepalives during quiet periods
After a client has sent us the complete pack, we may spend
some time processing the data and running hooks. If the
client asked us to be quiet, receive-pack won't send any
progress data during the index-pack or connectivity-check
steps. And hooks may or may not produce their own progress
output. In these cases, the network connection is totally
silent from both ends.
Git itself doesn't care about this (it will wait forever),
but other parts of the system (e.g., firewalls,
load-balancers, etc) might hang up the connection. So we'd
like to send some sort of keepalive to let the network and
the client side know that we're still alive and processing.
We can use the same trick we did in 05e9515 (upload-pack:
send keepalive packets during pack computation, 2013-09-08).
Namely, we will send an empty sideband data packet every `N`
seconds that we do not relay any stderr data over the
sideband channel. As with 05e9515, this means that we won't
bother sending keepalives when there's actual progress data,
but will kick in when it has been disabled (or if there is a
lull in the progress data).
The concept is simple, but the details are subtle enough
that they need discussing here.
Before the client sends us the pack, we don't want to do any
keepalives. We'll have sent our ref advertisement, and we're
waiting for them to send us the pack (and tell us that they
support sidebands at all).
While we're receiving the pack from the client (or waiting
for it to start), there's no need for keepalives; it's up to
them to keep the connection active by sending data.
Moreover, it would be wrong for us to do so. When we are the
server in the smart-http protocol, we must treat our
connection as half-duplex. So any keepalives we send while
receiving the pack would potentially be buffered by the
webserver. Not only does this make them useless (since they
would not be delivered in a timely manner), but it could
actually cause a deadlock if we fill up the buffer with
keepalives. (It wouldn't be wrong to send keepalives in this
phase for a full-duplex connection like ssh; it's simply
pointless, as it is the client's responsibility to speak).
As soon as we've gotten all of the pack data, then the
client is waiting for us to speak, and we should start
keepalives immediately. From here until the end of the
connection, we send one any time we are not otherwise
sending data.
But there's a catch. Receive-pack doesn't know the moment
we've gotten all the data. It passes the descriptor to
index-pack, who reads all of the data, and then starts
resolving the deltas. We have to communicate that back.
To make this work, we instruct the sideband muxer to enable
keepalives in three phases:
1. In the beginning, not at all.
2. While reading from index-pack, wait for a signal
indicating end-of-input, and then start them.
3. Afterwards, always.
The signal from index-pack in phase 2 has to come over the
stderr channel which the muxer is reading. We can't use an
extra pipe because the portable run-command interface only
gives us stderr and stdout.
Stdout is already used to pass the .keep filename back to
receive-pack. We could also send a signal there, but then we
would find out about it in the main thread. And the
keepalive needs to be done by the async muxer thread (since
it's the one writing sideband data back to the client). And
we can't reliably signal the async thread from the main
thread, because the async code sometimes uses threads and
sometimes uses forked processes.
Therefore the signal must come over the stderr channel,
where it may be interspersed with other random
human-readable messages from index-pack. This patch makes
the signal a single NUL byte. This is easy to parse, should
not appear in any normal stderr output, and we don't have to
worry about any timing issues (like seeing half the signal
bytes in one read(), and half in a subsequent one).
This is a bit ugly, but it's simple to code and should work
reliably.
Another option would be to stop using an async thread for
muxing entirely, and just poll() both stderr and stdout of
index-pack from the main thread. This would work for
index-pack (because we aren't doing anything useful in the
main thread while it runs anyway). But it would make the
connectivity check and the hook muxers much more
complicated, as they need to simultaneously feed the
sub-programs while reading their stderr.
The index-pack phase is the only one that needs this
signaling, so it could simply behave differently than the
other two. That would mean having two separate
implementations of copy_to_sideband (and the keepalive
code), though. And it still doesn't get rid of the
signaling; it just means we can write a nicer message like
"END_OF_INPUT" or something on stdout, since we don't have
to worry about separating it from the stderr cruft.
One final note: this signaling trick is only done with
index-pack, not with unpack-objects. There's no point in
doing it for the latter, because by definition it only kicks
in for a small number of objects, where keepalives are not
as useful (and this conveniently lets us avoid duplicating
the implementation).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-15 10:43:47 +00:00
|
|
|
if (strcmp(var, "receive.keepalive") == 0) {
|
|
|
|
keepalive_in_sec = git_config_int(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-08-24 18:41:57 +00:00
|
|
|
if (strcmp(var, "receive.maxinputsize") == 0) {
|
|
|
|
max_input_size = git_config_int64(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-08-27 15:45:48 +00:00
|
|
|
if (strcmp(var, "receive.procreceiverefs") == 0) {
|
|
|
|
if (!value)
|
|
|
|
return config_error_nonbool(var);
|
|
|
|
proc_receive_ref_append(value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-11-11 23:29:28 +00:00
|
|
|
if (strcmp(var, "transfer.advertisesid") == 0) {
|
|
|
|
advertise_sid = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-05-14 17:46:53 +00:00
|
|
|
return git_default_config(var, value, cb);
|
2006-10-30 22:35:18 +00:00
|
|
|
}
|
|
|
|
|
2017-03-31 01:39:59 +00:00
|
|
|
static void show_ref(const char *path, const struct object_id *oid)
|
2005-06-30 00:52:11 +00:00
|
|
|
{
|
2014-09-04 19:13:32 +00:00
|
|
|
if (sent_capabilities) {
|
2017-03-31 01:39:59 +00:00
|
|
|
packet_write_fmt(1, "%s %s\n", oid_to_hex(oid), path);
|
2014-09-04 19:13:32 +00:00
|
|
|
} else {
|
|
|
|
struct strbuf cap = STRBUF_INIT;
|
|
|
|
|
|
|
|
strbuf_addstr(&cap,
|
2020-08-27 15:45:46 +00:00
|
|
|
"report-status report-status-v2 delete-refs side-band-64k quiet");
|
2015-01-08 03:23:20 +00:00
|
|
|
if (advertise_atomic_push)
|
|
|
|
strbuf_addstr(&cap, " atomic");
|
2014-09-04 19:13:32 +00:00
|
|
|
if (prefer_ofs_delta)
|
|
|
|
strbuf_addstr(&cap, " ofs-delta");
|
2014-08-21 23:45:30 +00:00
|
|
|
if (push_cert_nonce)
|
|
|
|
strbuf_addf(&cap, " push-cert=%s", push_cert_nonce);
|
2016-07-14 21:49:46 +00:00
|
|
|
if (advertise_push_options)
|
|
|
|
strbuf_addstr(&cap, " push-options");
|
2020-11-11 23:29:28 +00:00
|
|
|
if (advertise_sid)
|
|
|
|
strbuf_addf(&cap, " session-id=%s", trace2_session_id());
|
2020-05-25 19:58:51 +00:00
|
|
|
strbuf_addf(&cap, " object-format=%s", the_hash_algo->name);
|
2014-09-04 19:13:32 +00:00
|
|
|
strbuf_addf(&cap, " agent=%s", git_user_agent_sanitized());
|
2016-10-16 23:20:29 +00:00
|
|
|
packet_write_fmt(1, "%s %s%c%s\n",
|
2017-03-31 01:39:59 +00:00
|
|
|
oid_to_hex(oid), path, 0, cap.buf);
|
2014-09-04 19:13:32 +00:00
|
|
|
strbuf_release(&cap);
|
|
|
|
sent_capabilities = 1;
|
|
|
|
}
|
2005-06-30 00:52:11 +00:00
|
|
|
}
|
|
|
|
|
2015-11-03 07:58:16 +00:00
|
|
|
static int show_ref_cb(const char *path_full, const struct object_id *oid,
|
2022-08-25 17:09:48 +00:00
|
|
|
int flag UNUSED, void *data)
|
2011-07-08 23:13:32 +00:00
|
|
|
{
|
2017-02-08 20:53:16 +00:00
|
|
|
struct oidset *seen = data;
|
2015-11-03 07:58:16 +00:00
|
|
|
const char *path = strip_namespace(path_full);
|
|
|
|
|
2022-11-17 05:46:43 +00:00
|
|
|
if (ref_is_hidden(path, path_full, &hidden_refs))
|
2015-11-03 07:58:16 +00:00
|
|
|
return 0;
|
|
|
|
|
2011-07-08 23:13:32 +00:00
|
|
|
/*
|
|
|
|
* Advertise refs outside our current namespace as ".have"
|
|
|
|
* refs, so that the client can use them to minimize data
|
2017-02-08 20:53:13 +00:00
|
|
|
* transfer but will otherwise ignore them.
|
2011-07-08 23:13:32 +00:00
|
|
|
*/
|
2017-02-08 20:53:16 +00:00
|
|
|
if (!path) {
|
|
|
|
if (oidset_insert(seen, oid))
|
|
|
|
return 0;
|
2011-07-08 23:13:32 +00:00
|
|
|
path = ".have";
|
2017-02-08 20:53:19 +00:00
|
|
|
} else {
|
|
|
|
oidset_insert(seen, oid);
|
2017-02-08 20:53:16 +00:00
|
|
|
}
|
2017-03-31 01:39:59 +00:00
|
|
|
show_ref(path, oid);
|
2012-01-06 14:12:32 +00:00
|
|
|
return 0;
|
2011-07-08 23:13:32 +00:00
|
|
|
}
|
|
|
|
|
2018-10-08 18:09:23 +00:00
|
|
|
static void show_one_alternate_ref(const struct object_id *oid,
|
receive-pack: use oidset to de-duplicate .have lines
If you have an alternate object store with a very large
number of refs, the peak memory usage of the sha1_array can
grow high, even if most of them are duplicates that end up
not being printed at all.
The similar for_each_alternate_ref() code-paths in
fetch-pack solve this by using flags in "struct object" to
de-duplicate (and so are relying on obj_hash at the core).
But we don't have a "struct object" at all in this case. We
could call lookup_unknown_object() to get one, but if our
goal is reducing memory footprint, it's not great:
- an unknown object is as large as the largest object type
(a commit), which is bigger than an oidset entry
- we can free the memory after our ref advertisement, but
"struct object" entries persist forever (and the
receive-pack may hang around for a long time, as the
bottleneck is often client upload bandwidth).
So let's use an oidset. Note that unlike a sha1-array it
doesn't sort the output as a side effect. However, our
output is at least stable, because for_each_alternate_ref()
will give us the sha1s in ref-sorted order.
In one particularly pathological case with an alternate that
has 60,000 unique refs out of 80 million total, this reduced
the peak heap usage of "git receive-pack . </dev/null" from
13GB to 14MB.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08 20:53:10 +00:00
|
|
|
void *data)
|
2012-01-06 14:12:31 +00:00
|
|
|
{
|
receive-pack: use oidset to de-duplicate .have lines
If you have an alternate object store with a very large
number of refs, the peak memory usage of the sha1_array can
grow high, even if most of them are duplicates that end up
not being printed at all.
The similar for_each_alternate_ref() code-paths in
fetch-pack solve this by using flags in "struct object" to
de-duplicate (and so are relying on obj_hash at the core).
But we don't have a "struct object" at all in this case. We
could call lookup_unknown_object() to get one, but if our
goal is reducing memory footprint, it's not great:
- an unknown object is as large as the largest object type
(a commit), which is bigger than an oidset entry
- we can free the memory after our ref advertisement, but
"struct object" entries persist forever (and the
receive-pack may hang around for a long time, as the
bottleneck is often client upload bandwidth).
So let's use an oidset. Note that unlike a sha1-array it
doesn't sort the output as a side effect. However, our
output is at least stable, because for_each_alternate_ref()
will give us the sha1s in ref-sorted order.
In one particularly pathological case with an alternate that
has 60,000 unique refs out of 80 million total, this reduced
the peak heap usage of "git receive-pack . </dev/null" from
13GB to 14MB.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08 20:53:10 +00:00
|
|
|
struct oidset *seen = data;
|
2012-01-06 14:12:31 +00:00
|
|
|
|
receive-pack: use oidset to de-duplicate .have lines
If you have an alternate object store with a very large
number of refs, the peak memory usage of the sha1_array can
grow high, even if most of them are duplicates that end up
not being printed at all.
The similar for_each_alternate_ref() code-paths in
fetch-pack solve this by using flags in "struct object" to
de-duplicate (and so are relying on obj_hash at the core).
But we don't have a "struct object" at all in this case. We
could call lookup_unknown_object() to get one, but if our
goal is reducing memory footprint, it's not great:
- an unknown object is as large as the largest object type
(a commit), which is bigger than an oidset entry
- we can free the memory after our ref advertisement, but
"struct object" entries persist forever (and the
receive-pack may hang around for a long time, as the
bottleneck is often client upload bandwidth).
So let's use an oidset. Note that unlike a sha1-array it
doesn't sort the output as a side effect. However, our
output is at least stable, because for_each_alternate_ref()
will give us the sha1s in ref-sorted order.
In one particularly pathological case with an alternate that
has 60,000 unique refs out of 80 million total, this reduced
the peak heap usage of "git receive-pack . </dev/null" from
13GB to 14MB.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08 20:53:10 +00:00
|
|
|
if (oidset_insert(seen, oid))
|
|
|
|
return;
|
|
|
|
|
2017-03-31 01:39:59 +00:00
|
|
|
show_ref(".have", oid);
|
2011-07-08 23:13:32 +00:00
|
|
|
}
|
|
|
|
|
2005-07-03 03:23:36 +00:00
|
|
|
static void write_head_info(void)
|
2005-06-30 00:52:11 +00:00
|
|
|
{
|
receive-pack: use oidset to de-duplicate .have lines
If you have an alternate object store with a very large
number of refs, the peak memory usage of the sha1_array can
grow high, even if most of them are duplicates that end up
not being printed at all.
The similar for_each_alternate_ref() code-paths in
fetch-pack solve this by using flags in "struct object" to
de-duplicate (and so are relying on obj_hash at the core).
But we don't have a "struct object" at all in this case. We
could call lookup_unknown_object() to get one, but if our
goal is reducing memory footprint, it's not great:
- an unknown object is as large as the largest object type
(a commit), which is bigger than an oidset entry
- we can free the memory after our ref advertisement, but
"struct object" entries persist forever (and the
receive-pack may hang around for a long time, as the
bottleneck is often client upload bandwidth).
So let's use an oidset. Note that unlike a sha1-array it
doesn't sort the output as a side effect. However, our
output is at least stable, because for_each_alternate_ref()
will give us the sha1s in ref-sorted order.
In one particularly pathological case with an alternate that
has 60,000 unique refs out of 80 million total, this reduced
the peak heap usage of "git receive-pack . </dev/null" from
13GB to 14MB.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08 20:53:10 +00:00
|
|
|
static struct oidset seen = OIDSET_INIT;
|
2015-05-25 18:38:28 +00:00
|
|
|
|
2017-02-08 20:53:19 +00:00
|
|
|
for_each_ref(show_ref_cb, &seen);
|
receive-pack: use oidset to de-duplicate .have lines
If you have an alternate object store with a very large
number of refs, the peak memory usage of the sha1_array can
grow high, even if most of them are duplicates that end up
not being printed at all.
The similar for_each_alternate_ref() code-paths in
fetch-pack solve this by using flags in "struct object" to
de-duplicate (and so are relying on obj_hash at the core).
But we don't have a "struct object" at all in this case. We
could call lookup_unknown_object() to get one, but if our
goal is reducing memory footprint, it's not great:
- an unknown object is as large as the largest object type
(a commit), which is bigger than an oidset entry
- we can free the memory after our ref advertisement, but
"struct object" entries persist forever (and the
receive-pack may hang around for a long time, as the
bottleneck is often client upload bandwidth).
So let's use an oidset. Note that unlike a sha1-array it
doesn't sort the output as a side effect. However, our
output is at least stable, because for_each_alternate_ref()
will give us the sha1s in ref-sorted order.
In one particularly pathological case with an alternate that
has 60,000 unique refs out of 80 million total, this reduced
the peak heap usage of "git receive-pack . </dev/null" from
13GB to 14MB.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08 20:53:10 +00:00
|
|
|
for_each_alternate_ref(show_one_alternate_ref, &seen);
|
|
|
|
oidset_clear(&seen);
|
2010-02-05 20:57:40 +00:00
|
|
|
if (!sent_capabilities)
|
2021-04-26 01:02:56 +00:00
|
|
|
show_ref("capabilities^{}", null_oid());
|
2005-12-26 07:18:37 +00:00
|
|
|
|
2013-12-05 13:02:32 +00:00
|
|
|
advertise_shallow_grafts(1);
|
|
|
|
|
2012-01-06 14:12:31 +00:00
|
|
|
/* EOF */
|
|
|
|
packet_flush(1);
|
2005-06-30 00:52:11 +00:00
|
|
|
}
|
|
|
|
|
receive-pack: add new proc-receive hook
Git calls an internal `execute_commands` function to handle commands
sent from client to `git-receive-pack`. Regardless of what references
the user pushes, git creates or updates the corresponding references if
the user has write-permission. A contributor who has no
write-permission, cannot push to the repository directly. So, the
contributor has to write commits to an alternate location, and sends
pull request by emails or by other ways. We call this workflow as a
distributed workflow.
It would be more convenient to work in a centralized workflow like what
Gerrit provided for some cases. For example, a read-only user who
cannot push to a branch directly can run the following `git push`
command to push commits to a pseudo reference (has a prefix "refs/for/",
not "refs/heads/") to create a code review.
git push origin \
HEAD:refs/for/<branch-name>/<session>
The `<branch-name>` in the above example can be as simple as "master",
or a more complicated branch name like "foo/bar". The `<session>` in
the above example command can be the local branch name of the client
side, such as "my/topic".
We cannot implement a centralized workflow elegantly by using
"pre-receive" + "post-receive", because Git will call the internal
function "execute_commands" to create references (even the special
pseudo reference) between these two hooks. Even though we can delete
the temporarily created pseudo reference via the "post-receive" hook,
having a temporary reference is not safe for concurrent pushes.
So, add a filter and a new handler to support this kind of workflow.
The filter will check the prefix of the reference name, and if the
command has a special reference name, the filter will turn a specific
field (`run_proc_receive`) on for the command. Commands with this filed
turned on will be executed by a new handler (a hook named
"proc-receive") instead of the internal `execute_commands` function.
We can use this "proc-receive" command to create pull requests or send
emails for code review.
Suggested by Junio, this "proc-receive" hook reads the commands,
push-options (optional), and send result using a protocol in pkt-line
format. In the following example, the letter "S" stands for
"receive-pack" and letter "H" stands for the hook.
# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive result from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' to execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference. The alternate reference name
# and other status can be given in options
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt
After receiving a command, the hook will execute the command, and may
create/update different reference. For example, a command for a pseudo
reference "refs/for/master/topic" may create/update different reference
such as "refs/pull/123/head". The alternate reference name and other
status are given in option lines.
The list of commands returned from "proc-receive" will replace the
relevant commands that are sent from user to "receive-pack", and
"receive-pack" will continue to run the "execute_commands" function and
other routines. Finally, the result of the execution of these commands
will be reported to end user.
The reporting function from "receive-pack" to "send-pack" will be
extended in latter commit just like what the "proc-receive" hook reports
to "receive-pack".
Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27 15:45:44 +00:00
|
|
|
#define RUN_PROC_RECEIVE_SCHEDULED 1
|
|
|
|
#define RUN_PROC_RECEIVE_RETURNED 2
|
2005-06-30 06:01:14 +00:00
|
|
|
struct command {
|
|
|
|
struct command *next;
|
2005-12-26 07:18:37 +00:00
|
|
|
const char *error_string;
|
receive-pack: add new proc-receive hook
Git calls an internal `execute_commands` function to handle commands
sent from client to `git-receive-pack`. Regardless of what references
the user pushes, git creates or updates the corresponding references if
the user has write-permission. A contributor who has no
write-permission, cannot push to the repository directly. So, the
contributor has to write commits to an alternate location, and sends
pull request by emails or by other ways. We call this workflow as a
distributed workflow.
It would be more convenient to work in a centralized workflow like what
Gerrit provided for some cases. For example, a read-only user who
cannot push to a branch directly can run the following `git push`
command to push commits to a pseudo reference (has a prefix "refs/for/",
not "refs/heads/") to create a code review.
git push origin \
HEAD:refs/for/<branch-name>/<session>
The `<branch-name>` in the above example can be as simple as "master",
or a more complicated branch name like "foo/bar". The `<session>` in
the above example command can be the local branch name of the client
side, such as "my/topic".
We cannot implement a centralized workflow elegantly by using
"pre-receive" + "post-receive", because Git will call the internal
function "execute_commands" to create references (even the special
pseudo reference) between these two hooks. Even though we can delete
the temporarily created pseudo reference via the "post-receive" hook,
having a temporary reference is not safe for concurrent pushes.
So, add a filter and a new handler to support this kind of workflow.
The filter will check the prefix of the reference name, and if the
command has a special reference name, the filter will turn a specific
field (`run_proc_receive`) on for the command. Commands with this filed
turned on will be executed by a new handler (a hook named
"proc-receive") instead of the internal `execute_commands` function.
We can use this "proc-receive" command to create pull requests or send
emails for code review.
Suggested by Junio, this "proc-receive" hook reads the commands,
push-options (optional), and send result using a protocol in pkt-line
format. In the following example, the letter "S" stands for
"receive-pack" and letter "H" stands for the hook.
# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive result from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' to execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference. The alternate reference name
# and other status can be given in options
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt
After receiving a command, the hook will execute the command, and may
create/update different reference. For example, a command for a pseudo
reference "refs/for/master/topic" may create/update different reference
such as "refs/pull/123/head". The alternate reference name and other
status are given in option lines.
The list of commands returned from "proc-receive" will replace the
relevant commands that are sent from user to "receive-pack", and
"receive-pack" will continue to run the "execute_commands" function and
other routines. Finally, the result of the execution of these commands
will be reported to end user.
The reporting function from "receive-pack" to "send-pack" will be
extended in latter commit just like what the "proc-receive" hook reports
to "receive-pack".
Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27 15:45:44 +00:00
|
|
|
struct ref_push_report *report;
|
2011-09-28 15:39:35 +00:00
|
|
|
unsigned int skip_update:1,
|
receive-pack: add new proc-receive hook
Git calls an internal `execute_commands` function to handle commands
sent from client to `git-receive-pack`. Regardless of what references
the user pushes, git creates or updates the corresponding references if
the user has write-permission. A contributor who has no
write-permission, cannot push to the repository directly. So, the
contributor has to write commits to an alternate location, and sends
pull request by emails or by other ways. We call this workflow as a
distributed workflow.
It would be more convenient to work in a centralized workflow like what
Gerrit provided for some cases. For example, a read-only user who
cannot push to a branch directly can run the following `git push`
command to push commits to a pseudo reference (has a prefix "refs/for/",
not "refs/heads/") to create a code review.
git push origin \
HEAD:refs/for/<branch-name>/<session>
The `<branch-name>` in the above example can be as simple as "master",
or a more complicated branch name like "foo/bar". The `<session>` in
the above example command can be the local branch name of the client
side, such as "my/topic".
We cannot implement a centralized workflow elegantly by using
"pre-receive" + "post-receive", because Git will call the internal
function "execute_commands" to create references (even the special
pseudo reference) between these two hooks. Even though we can delete
the temporarily created pseudo reference via the "post-receive" hook,
having a temporary reference is not safe for concurrent pushes.
So, add a filter and a new handler to support this kind of workflow.
The filter will check the prefix of the reference name, and if the
command has a special reference name, the filter will turn a specific
field (`run_proc_receive`) on for the command. Commands with this filed
turned on will be executed by a new handler (a hook named
"proc-receive") instead of the internal `execute_commands` function.
We can use this "proc-receive" command to create pull requests or send
emails for code review.
Suggested by Junio, this "proc-receive" hook reads the commands,
push-options (optional), and send result using a protocol in pkt-line
format. In the following example, the letter "S" stands for
"receive-pack" and letter "H" stands for the hook.
# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive result from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' to execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference. The alternate reference name
# and other status can be given in options
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt
After receiving a command, the hook will execute the command, and may
create/update different reference. For example, a command for a pseudo
reference "refs/for/master/topic" may create/update different reference
such as "refs/pull/123/head". The alternate reference name and other
status are given in option lines.
The list of commands returned from "proc-receive" will replace the
relevant commands that are sent from user to "receive-pack", and
"receive-pack" will continue to run the "execute_commands" function and
other routines. Finally, the result of the execution of these commands
will be reported to end user.
The reporting function from "receive-pack" to "send-pack" will be
extended in latter commit just like what the "proc-receive" hook reports
to "receive-pack".
Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27 15:45:44 +00:00
|
|
|
did_not_exist:1,
|
|
|
|
run_proc_receive:2;
|
2013-12-05 13:02:44 +00:00
|
|
|
int index;
|
2017-03-26 16:01:29 +00:00
|
|
|
struct object_id old_oid;
|
|
|
|
struct object_id new_oid;
|
2006-01-07 09:33:54 +00:00
|
|
|
char ref_name[FLEX_ARRAY]; /* more */
|
2005-06-30 00:52:11 +00:00
|
|
|
};
|
|
|
|
|
2020-08-27 15:45:48 +00:00
|
|
|
static void proc_receive_ref_append(const char *prefix)
|
|
|
|
{
|
|
|
|
struct proc_receive_ref *ref_pattern;
|
|
|
|
char *p;
|
|
|
|
int len;
|
|
|
|
|
2021-03-13 16:17:22 +00:00
|
|
|
CALLOC_ARRAY(ref_pattern, 1);
|
2020-08-27 15:45:48 +00:00
|
|
|
p = strchr(prefix, ':');
|
|
|
|
if (p) {
|
|
|
|
while (prefix < p) {
|
|
|
|
if (*prefix == 'a')
|
|
|
|
ref_pattern->want_add = 1;
|
|
|
|
else if (*prefix == 'd')
|
|
|
|
ref_pattern->want_delete = 1;
|
|
|
|
else if (*prefix == 'm')
|
|
|
|
ref_pattern->want_modify = 1;
|
|
|
|
else if (*prefix == '!')
|
|
|
|
ref_pattern->negative_ref = 1;
|
|
|
|
prefix++;
|
|
|
|
}
|
|
|
|
prefix++;
|
|
|
|
} else {
|
|
|
|
ref_pattern->want_add = 1;
|
|
|
|
ref_pattern->want_delete = 1;
|
|
|
|
ref_pattern->want_modify = 1;
|
|
|
|
}
|
|
|
|
len = strlen(prefix);
|
|
|
|
while (len && prefix[len - 1] == '/')
|
|
|
|
len--;
|
|
|
|
ref_pattern->ref_prefix = xmemdupz(prefix, len);
|
|
|
|
if (!proc_receive_ref) {
|
|
|
|
proc_receive_ref = ref_pattern;
|
|
|
|
} else {
|
|
|
|
struct proc_receive_ref *end;
|
|
|
|
|
|
|
|
end = proc_receive_ref;
|
|
|
|
while (end->next)
|
|
|
|
end = end->next;
|
|
|
|
end->next = ref_pattern;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int proc_receive_ref_matches(struct command *cmd)
|
|
|
|
{
|
|
|
|
struct proc_receive_ref *p;
|
|
|
|
|
|
|
|
if (!proc_receive_ref)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
for (p = proc_receive_ref; p; p = p->next) {
|
|
|
|
const char *match = p->ref_prefix;
|
|
|
|
const char *remains;
|
|
|
|
|
|
|
|
if (!p->want_add && is_null_oid(&cmd->old_oid))
|
|
|
|
continue;
|
|
|
|
else if (!p->want_delete && is_null_oid(&cmd->new_oid))
|
|
|
|
continue;
|
|
|
|
else if (!p->want_modify &&
|
|
|
|
!is_null_oid(&cmd->old_oid) &&
|
|
|
|
!is_null_oid(&cmd->new_oid))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (skip_prefix(cmd->ref_name, match, &remains) &&
|
|
|
|
(!*remains || *remains == '/')) {
|
|
|
|
if (!p->negative_ref)
|
|
|
|
return 1;
|
|
|
|
} else if (p->negative_ref) {
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-02-10 17:34:12 +00:00
|
|
|
static void report_message(const char *prefix, const char *err, va_list params)
|
|
|
|
{
|
2015-09-24 21:07:00 +00:00
|
|
|
int sz;
|
2010-02-10 17:34:12 +00:00
|
|
|
char msg[4096];
|
|
|
|
|
2015-09-24 21:07:00 +00:00
|
|
|
sz = xsnprintf(msg, sizeof(msg), "%s", prefix);
|
2010-02-10 17:34:12 +00:00
|
|
|
sz += vsnprintf(msg + sz, sizeof(msg) - sz, err, params);
|
|
|
|
if (sz > (sizeof(msg) - 1))
|
|
|
|
sz = sizeof(msg) - 1;
|
|
|
|
msg[sz++] = '\n';
|
|
|
|
|
|
|
|
if (use_sideband)
|
|
|
|
send_sideband(1, 2, msg, sz, use_sideband);
|
|
|
|
else
|
|
|
|
xwrite(2, msg, sz);
|
|
|
|
}
|
|
|
|
|
2021-07-10 08:47:27 +00:00
|
|
|
__attribute__((format (printf, 1, 2)))
|
2010-02-10 17:34:12 +00:00
|
|
|
static void rp_warning(const char *err, ...)
|
|
|
|
{
|
|
|
|
va_list params;
|
|
|
|
va_start(params, err);
|
|
|
|
report_message("warning: ", err, params);
|
|
|
|
va_end(params);
|
|
|
|
}
|
|
|
|
|
2021-07-10 08:47:27 +00:00
|
|
|
__attribute__((format (printf, 1, 2)))
|
2010-02-10 17:34:12 +00:00
|
|
|
static void rp_error(const char *err, ...)
|
|
|
|
{
|
|
|
|
va_list params;
|
|
|
|
va_start(params, err);
|
|
|
|
report_message("error: ", err, params);
|
|
|
|
va_end(params);
|
|
|
|
}
|
|
|
|
|
2022-08-25 17:09:48 +00:00
|
|
|
static int copy_to_sideband(int in, int out UNUSED, void *arg UNUSED)
|
2010-02-05 20:57:42 +00:00
|
|
|
{
|
|
|
|
char data[128];
|
receive-pack: send keepalives during quiet periods
After a client has sent us the complete pack, we may spend
some time processing the data and running hooks. If the
client asked us to be quiet, receive-pack won't send any
progress data during the index-pack or connectivity-check
steps. And hooks may or may not produce their own progress
output. In these cases, the network connection is totally
silent from both ends.
Git itself doesn't care about this (it will wait forever),
but other parts of the system (e.g., firewalls,
load-balancers, etc) might hang up the connection. So we'd
like to send some sort of keepalive to let the network and
the client side know that we're still alive and processing.
We can use the same trick we did in 05e9515 (upload-pack:
send keepalive packets during pack computation, 2013-09-08).
Namely, we will send an empty sideband data packet every `N`
seconds that we do not relay any stderr data over the
sideband channel. As with 05e9515, this means that we won't
bother sending keepalives when there's actual progress data,
but will kick in when it has been disabled (or if there is a
lull in the progress data).
The concept is simple, but the details are subtle enough
that they need discussing here.
Before the client sends us the pack, we don't want to do any
keepalives. We'll have sent our ref advertisement, and we're
waiting for them to send us the pack (and tell us that they
support sidebands at all).
While we're receiving the pack from the client (or waiting
for it to start), there's no need for keepalives; it's up to
them to keep the connection active by sending data.
Moreover, it would be wrong for us to do so. When we are the
server in the smart-http protocol, we must treat our
connection as half-duplex. So any keepalives we send while
receiving the pack would potentially be buffered by the
webserver. Not only does this make them useless (since they
would not be delivered in a timely manner), but it could
actually cause a deadlock if we fill up the buffer with
keepalives. (It wouldn't be wrong to send keepalives in this
phase for a full-duplex connection like ssh; it's simply
pointless, as it is the client's responsibility to speak).
As soon as we've gotten all of the pack data, then the
client is waiting for us to speak, and we should start
keepalives immediately. From here until the end of the
connection, we send one any time we are not otherwise
sending data.
But there's a catch. Receive-pack doesn't know the moment
we've gotten all the data. It passes the descriptor to
index-pack, who reads all of the data, and then starts
resolving the deltas. We have to communicate that back.
To make this work, we instruct the sideband muxer to enable
keepalives in three phases:
1. In the beginning, not at all.
2. While reading from index-pack, wait for a signal
indicating end-of-input, and then start them.
3. Afterwards, always.
The signal from index-pack in phase 2 has to come over the
stderr channel which the muxer is reading. We can't use an
extra pipe because the portable run-command interface only
gives us stderr and stdout.
Stdout is already used to pass the .keep filename back to
receive-pack. We could also send a signal there, but then we
would find out about it in the main thread. And the
keepalive needs to be done by the async muxer thread (since
it's the one writing sideband data back to the client). And
we can't reliably signal the async thread from the main
thread, because the async code sometimes uses threads and
sometimes uses forked processes.
Therefore the signal must come over the stderr channel,
where it may be interspersed with other random
human-readable messages from index-pack. This patch makes
the signal a single NUL byte. This is easy to parse, should
not appear in any normal stderr output, and we don't have to
worry about any timing issues (like seeing half the signal
bytes in one read(), and half in a subsequent one).
This is a bit ugly, but it's simple to code and should work
reliably.
Another option would be to stop using an async thread for
muxing entirely, and just poll() both stderr and stdout of
index-pack from the main thread. This would work for
index-pack (because we aren't doing anything useful in the
main thread while it runs anyway). But it would make the
connectivity check and the hook muxers much more
complicated, as they need to simultaneously feed the
sub-programs while reading their stderr.
The index-pack phase is the only one that needs this
signaling, so it could simply behave differently than the
other two. That would mean having two separate
implementations of copy_to_sideband (and the keepalive
code), though. And it still doesn't get rid of the
signaling; it just means we can write a nicer message like
"END_OF_INPUT" or something on stdout, since we don't have
to worry about separating it from the stderr cruft.
One final note: this signaling trick is only done with
index-pack, not with unpack-objects. There's no point in
doing it for the latter, because by definition it only kicks
in for a small number of objects, where keepalives are not
as useful (and this conveniently lets us avoid duplicating
the implementation).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-15 10:43:47 +00:00
|
|
|
int keepalive_active = 0;
|
|
|
|
|
|
|
|
if (keepalive_in_sec <= 0)
|
|
|
|
use_keepalive = KEEPALIVE_NEVER;
|
|
|
|
if (use_keepalive == KEEPALIVE_ALWAYS)
|
|
|
|
keepalive_active = 1;
|
|
|
|
|
2010-02-05 20:57:42 +00:00
|
|
|
while (1) {
|
receive-pack: send keepalives during quiet periods
After a client has sent us the complete pack, we may spend
some time processing the data and running hooks. If the
client asked us to be quiet, receive-pack won't send any
progress data during the index-pack or connectivity-check
steps. And hooks may or may not produce their own progress
output. In these cases, the network connection is totally
silent from both ends.
Git itself doesn't care about this (it will wait forever),
but other parts of the system (e.g., firewalls,
load-balancers, etc) might hang up the connection. So we'd
like to send some sort of keepalive to let the network and
the client side know that we're still alive and processing.
We can use the same trick we did in 05e9515 (upload-pack:
send keepalive packets during pack computation, 2013-09-08).
Namely, we will send an empty sideband data packet every `N`
seconds that we do not relay any stderr data over the
sideband channel. As with 05e9515, this means that we won't
bother sending keepalives when there's actual progress data,
but will kick in when it has been disabled (or if there is a
lull in the progress data).
The concept is simple, but the details are subtle enough
that they need discussing here.
Before the client sends us the pack, we don't want to do any
keepalives. We'll have sent our ref advertisement, and we're
waiting for them to send us the pack (and tell us that they
support sidebands at all).
While we're receiving the pack from the client (or waiting
for it to start), there's no need for keepalives; it's up to
them to keep the connection active by sending data.
Moreover, it would be wrong for us to do so. When we are the
server in the smart-http protocol, we must treat our
connection as half-duplex. So any keepalives we send while
receiving the pack would potentially be buffered by the
webserver. Not only does this make them useless (since they
would not be delivered in a timely manner), but it could
actually cause a deadlock if we fill up the buffer with
keepalives. (It wouldn't be wrong to send keepalives in this
phase for a full-duplex connection like ssh; it's simply
pointless, as it is the client's responsibility to speak).
As soon as we've gotten all of the pack data, then the
client is waiting for us to speak, and we should start
keepalives immediately. From here until the end of the
connection, we send one any time we are not otherwise
sending data.
But there's a catch. Receive-pack doesn't know the moment
we've gotten all the data. It passes the descriptor to
index-pack, who reads all of the data, and then starts
resolving the deltas. We have to communicate that back.
To make this work, we instruct the sideband muxer to enable
keepalives in three phases:
1. In the beginning, not at all.
2. While reading from index-pack, wait for a signal
indicating end-of-input, and then start them.
3. Afterwards, always.
The signal from index-pack in phase 2 has to come over the
stderr channel which the muxer is reading. We can't use an
extra pipe because the portable run-command interface only
gives us stderr and stdout.
Stdout is already used to pass the .keep filename back to
receive-pack. We could also send a signal there, but then we
would find out about it in the main thread. And the
keepalive needs to be done by the async muxer thread (since
it's the one writing sideband data back to the client). And
we can't reliably signal the async thread from the main
thread, because the async code sometimes uses threads and
sometimes uses forked processes.
Therefore the signal must come over the stderr channel,
where it may be interspersed with other random
human-readable messages from index-pack. This patch makes
the signal a single NUL byte. This is easy to parse, should
not appear in any normal stderr output, and we don't have to
worry about any timing issues (like seeing half the signal
bytes in one read(), and half in a subsequent one).
This is a bit ugly, but it's simple to code and should work
reliably.
Another option would be to stop using an async thread for
muxing entirely, and just poll() both stderr and stdout of
index-pack from the main thread. This would work for
index-pack (because we aren't doing anything useful in the
main thread while it runs anyway). But it would make the
connectivity check and the hook muxers much more
complicated, as they need to simultaneously feed the
sub-programs while reading their stderr.
The index-pack phase is the only one that needs this
signaling, so it could simply behave differently than the
other two. That would mean having two separate
implementations of copy_to_sideband (and the keepalive
code), though. And it still doesn't get rid of the
signaling; it just means we can write a nicer message like
"END_OF_INPUT" or something on stdout, since we don't have
to worry about separating it from the stderr cruft.
One final note: this signaling trick is only done with
index-pack, not with unpack-objects. There's no point in
doing it for the latter, because by definition it only kicks
in for a small number of objects, where keepalives are not
as useful (and this conveniently lets us avoid duplicating
the implementation).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-15 10:43:47 +00:00
|
|
|
ssize_t sz;
|
|
|
|
|
|
|
|
if (keepalive_active) {
|
|
|
|
struct pollfd pfd;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
pfd.fd = in;
|
|
|
|
pfd.events = POLLIN;
|
|
|
|
ret = poll(&pfd, 1, 1000 * keepalive_in_sec);
|
|
|
|
|
|
|
|
if (ret < 0) {
|
|
|
|
if (errno == EINTR)
|
|
|
|
continue;
|
|
|
|
else
|
|
|
|
break;
|
|
|
|
} else if (ret == 0) {
|
|
|
|
/* no data; send a keepalive packet */
|
|
|
|
static const char buf[] = "0005\1";
|
|
|
|
write_or_die(1, buf, sizeof(buf) - 1);
|
|
|
|
continue;
|
|
|
|
} /* else there is actual data to read */
|
|
|
|
}
|
|
|
|
|
|
|
|
sz = xread(in, data, sizeof(data));
|
2010-02-05 20:57:42 +00:00
|
|
|
if (sz <= 0)
|
|
|
|
break;
|
receive-pack: send keepalives during quiet periods
After a client has sent us the complete pack, we may spend
some time processing the data and running hooks. If the
client asked us to be quiet, receive-pack won't send any
progress data during the index-pack or connectivity-check
steps. And hooks may or may not produce their own progress
output. In these cases, the network connection is totally
silent from both ends.
Git itself doesn't care about this (it will wait forever),
but other parts of the system (e.g., firewalls,
load-balancers, etc) might hang up the connection. So we'd
like to send some sort of keepalive to let the network and
the client side know that we're still alive and processing.
We can use the same trick we did in 05e9515 (upload-pack:
send keepalive packets during pack computation, 2013-09-08).
Namely, we will send an empty sideband data packet every `N`
seconds that we do not relay any stderr data over the
sideband channel. As with 05e9515, this means that we won't
bother sending keepalives when there's actual progress data,
but will kick in when it has been disabled (or if there is a
lull in the progress data).
The concept is simple, but the details are subtle enough
that they need discussing here.
Before the client sends us the pack, we don't want to do any
keepalives. We'll have sent our ref advertisement, and we're
waiting for them to send us the pack (and tell us that they
support sidebands at all).
While we're receiving the pack from the client (or waiting
for it to start), there's no need for keepalives; it's up to
them to keep the connection active by sending data.
Moreover, it would be wrong for us to do so. When we are the
server in the smart-http protocol, we must treat our
connection as half-duplex. So any keepalives we send while
receiving the pack would potentially be buffered by the
webserver. Not only does this make them useless (since they
would not be delivered in a timely manner), but it could
actually cause a deadlock if we fill up the buffer with
keepalives. (It wouldn't be wrong to send keepalives in this
phase for a full-duplex connection like ssh; it's simply
pointless, as it is the client's responsibility to speak).
As soon as we've gotten all of the pack data, then the
client is waiting for us to speak, and we should start
keepalives immediately. From here until the end of the
connection, we send one any time we are not otherwise
sending data.
But there's a catch. Receive-pack doesn't know the moment
we've gotten all the data. It passes the descriptor to
index-pack, who reads all of the data, and then starts
resolving the deltas. We have to communicate that back.
To make this work, we instruct the sideband muxer to enable
keepalives in three phases:
1. In the beginning, not at all.
2. While reading from index-pack, wait for a signal
indicating end-of-input, and then start them.
3. Afterwards, always.
The signal from index-pack in phase 2 has to come over the
stderr channel which the muxer is reading. We can't use an
extra pipe because the portable run-command interface only
gives us stderr and stdout.
Stdout is already used to pass the .keep filename back to
receive-pack. We could also send a signal there, but then we
would find out about it in the main thread. And the
keepalive needs to be done by the async muxer thread (since
it's the one writing sideband data back to the client). And
we can't reliably signal the async thread from the main
thread, because the async code sometimes uses threads and
sometimes uses forked processes.
Therefore the signal must come over the stderr channel,
where it may be interspersed with other random
human-readable messages from index-pack. This patch makes
the signal a single NUL byte. This is easy to parse, should
not appear in any normal stderr output, and we don't have to
worry about any timing issues (like seeing half the signal
bytes in one read(), and half in a subsequent one).
This is a bit ugly, but it's simple to code and should work
reliably.
Another option would be to stop using an async thread for
muxing entirely, and just poll() both stderr and stdout of
index-pack from the main thread. This would work for
index-pack (because we aren't doing anything useful in the
main thread while it runs anyway). But it would make the
connectivity check and the hook muxers much more
complicated, as they need to simultaneously feed the
sub-programs while reading their stderr.
The index-pack phase is the only one that needs this
signaling, so it could simply behave differently than the
other two. That would mean having two separate
implementations of copy_to_sideband (and the keepalive
code), though. And it still doesn't get rid of the
signaling; it just means we can write a nicer message like
"END_OF_INPUT" or something on stdout, since we don't have
to worry about separating it from the stderr cruft.
One final note: this signaling trick is only done with
index-pack, not with unpack-objects. There's no point in
doing it for the latter, because by definition it only kicks
in for a small number of objects, where keepalives are not
as useful (and this conveniently lets us avoid duplicating
the implementation).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-15 10:43:47 +00:00
|
|
|
|
|
|
|
if (use_keepalive == KEEPALIVE_AFTER_NUL && !keepalive_active) {
|
|
|
|
const char *p = memchr(data, '\0', sz);
|
|
|
|
if (p) {
|
|
|
|
/*
|
|
|
|
* The NUL tells us to start sending keepalives. Make
|
|
|
|
* sure we send any other data we read along
|
|
|
|
* with it.
|
|
|
|
*/
|
|
|
|
keepalive_active = 1;
|
|
|
|
send_sideband(1, 2, data, p - data, use_sideband);
|
|
|
|
send_sideband(1, 2, p + 1, sz - (p - data + 1), use_sideband);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Either we're not looking for a NUL signal, or we didn't see
|
|
|
|
* it yet; just pass along the data.
|
|
|
|
*/
|
2010-02-05 20:57:42 +00:00
|
|
|
send_sideband(1, 2, data, sz, use_sideband);
|
|
|
|
}
|
|
|
|
close(in);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
builtin/receive-pack: avoid generic function name hmac()
fabec2c5c3 (builtin/receive-pack: switch to use the_hash_algo, 2019-08-18)
renames hmac_sha1 to hmac, as it was updated to use the hash function used
by git (which won't be sha1 in the future).
hmac() is provided by NetBSD >= 8 libc and therefore conflicts as shown by :
builtin/receive-pack.c:421:13: error: conflicting types for 'hmac'
static void hmac(unsigned char *out,
^~~~
In file included from ./git-compat-util.h:172:0,
from ./builtin.h:4,
from builtin/receive-pack.c:1:
/usr/include/stdlib.h:305:10: note: previous declaration of 'hmac' was here
ssize_t hmac(const char *, const void *, size_t, const void *, size_t, void *,
^~~~
Rename it again to hmac_hash to reflect it will use the git's defined hash
function and avoid the conflict, while at it update a comment to better
describe the HMAC function that was used.
Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-05 09:53:26 +00:00
|
|
|
static void hmac_hash(unsigned char *out,
|
2014-08-21 23:45:30 +00:00
|
|
|
const char *key_in, size_t key_len,
|
|
|
|
const char *text, size_t text_len)
|
|
|
|
{
|
2019-08-18 20:04:05 +00:00
|
|
|
unsigned char key[GIT_MAX_BLKSZ];
|
|
|
|
unsigned char k_ipad[GIT_MAX_BLKSZ];
|
|
|
|
unsigned char k_opad[GIT_MAX_BLKSZ];
|
2014-08-21 23:45:30 +00:00
|
|
|
int i;
|
2019-08-18 20:04:05 +00:00
|
|
|
git_hash_ctx ctx;
|
2014-08-21 23:45:30 +00:00
|
|
|
|
|
|
|
/* RFC 2104 2. (1) */
|
2019-08-18 20:04:05 +00:00
|
|
|
memset(key, '\0', GIT_MAX_BLKSZ);
|
|
|
|
if (the_hash_algo->blksz < key_len) {
|
|
|
|
the_hash_algo->init_fn(&ctx);
|
|
|
|
the_hash_algo->update_fn(&ctx, key_in, key_len);
|
|
|
|
the_hash_algo->final_fn(key, &ctx);
|
2014-08-21 23:45:30 +00:00
|
|
|
} else {
|
|
|
|
memcpy(key, key_in, key_len);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* RFC 2104 2. (2) & (5) */
|
|
|
|
for (i = 0; i < sizeof(key); i++) {
|
|
|
|
k_ipad[i] = key[i] ^ 0x36;
|
|
|
|
k_opad[i] = key[i] ^ 0x5c;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* RFC 2104 2. (3) & (4) */
|
2019-08-18 20:04:05 +00:00
|
|
|
the_hash_algo->init_fn(&ctx);
|
|
|
|
the_hash_algo->update_fn(&ctx, k_ipad, sizeof(k_ipad));
|
|
|
|
the_hash_algo->update_fn(&ctx, text, text_len);
|
|
|
|
the_hash_algo->final_fn(out, &ctx);
|
2014-08-21 23:45:30 +00:00
|
|
|
|
|
|
|
/* RFC 2104 2. (6) & (7) */
|
2019-08-18 20:04:05 +00:00
|
|
|
the_hash_algo->init_fn(&ctx);
|
|
|
|
the_hash_algo->update_fn(&ctx, k_opad, sizeof(k_opad));
|
|
|
|
the_hash_algo->update_fn(&ctx, out, the_hash_algo->rawsz);
|
|
|
|
the_hash_algo->final_fn(out, &ctx);
|
2014-08-21 23:45:30 +00:00
|
|
|
}
|
|
|
|
|
2017-04-26 19:29:31 +00:00
|
|
|
static char *prepare_push_cert_nonce(const char *path, timestamp_t stamp)
|
2014-08-21 23:45:30 +00:00
|
|
|
{
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2019-08-18 20:04:05 +00:00
|
|
|
unsigned char hash[GIT_MAX_RAWSZ];
|
2014-08-21 23:45:30 +00:00
|
|
|
|
2017-04-21 10:45:48 +00:00
|
|
|
strbuf_addf(&buf, "%s:%"PRItime, path, stamp);
|
builtin/receive-pack: avoid generic function name hmac()
fabec2c5c3 (builtin/receive-pack: switch to use the_hash_algo, 2019-08-18)
renames hmac_sha1 to hmac, as it was updated to use the hash function used
by git (which won't be sha1 in the future).
hmac() is provided by NetBSD >= 8 libc and therefore conflicts as shown by :
builtin/receive-pack.c:421:13: error: conflicting types for 'hmac'
static void hmac(unsigned char *out,
^~~~
In file included from ./git-compat-util.h:172:0,
from ./builtin.h:4,
from builtin/receive-pack.c:1:
/usr/include/stdlib.h:305:10: note: previous declaration of 'hmac' was here
ssize_t hmac(const char *, const void *, size_t, const void *, size_t, void *,
^~~~
Rename it again to hmac_hash to reflect it will use the git's defined hash
function and avoid the conflict, while at it update a comment to better
describe the HMAC function that was used.
Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-05 09:53:26 +00:00
|
|
|
hmac_hash(hash, buf.buf, buf.len, cert_nonce_seed, strlen(cert_nonce_seed));
|
2014-08-21 23:45:30 +00:00
|
|
|
strbuf_release(&buf);
|
|
|
|
|
builtin/receive-pack: avoid generic function name hmac()
fabec2c5c3 (builtin/receive-pack: switch to use the_hash_algo, 2019-08-18)
renames hmac_sha1 to hmac, as it was updated to use the hash function used
by git (which won't be sha1 in the future).
hmac() is provided by NetBSD >= 8 libc and therefore conflicts as shown by :
builtin/receive-pack.c:421:13: error: conflicting types for 'hmac'
static void hmac(unsigned char *out,
^~~~
In file included from ./git-compat-util.h:172:0,
from ./builtin.h:4,
from builtin/receive-pack.c:1:
/usr/include/stdlib.h:305:10: note: previous declaration of 'hmac' was here
ssize_t hmac(const char *, const void *, size_t, const void *, size_t, void *,
^~~~
Rename it again to hmac_hash to reflect it will use the git's defined hash
function and avoid the conflict, while at it update a comment to better
describe the HMAC function that was used.
Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-05 09:53:26 +00:00
|
|
|
/* RFC 2104 5. HMAC-SHA1 or HMAC-SHA256 */
|
2019-08-18 20:04:24 +00:00
|
|
|
strbuf_addf(&buf, "%"PRItime"-%.*s", stamp, (int)the_hash_algo->hexsz, hash_to_hex(hash));
|
2014-08-21 23:45:30 +00:00
|
|
|
return strbuf_detach(&buf, NULL);
|
|
|
|
}
|
|
|
|
|
2017-05-09 19:23:53 +00:00
|
|
|
static char *find_header(const char *msg, size_t len, const char *key,
|
|
|
|
const char **next_line)
|
2014-08-21 23:45:30 +00:00
|
|
|
{
|
2022-01-06 20:07:35 +00:00
|
|
|
size_t out_len;
|
|
|
|
const char *val = find_header_mem(msg, len, key, &out_len);
|
|
|
|
|
|
|
|
if (!val)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
if (next_line)
|
|
|
|
*next_line = val + out_len + 1;
|
|
|
|
|
|
|
|
return xmemdupz(val, out_len);
|
2014-08-21 23:45:30 +00:00
|
|
|
}
|
|
|
|
|
builtin/receive-pack: use constant-time comparison for HMAC value
When we're comparing a push cert nonce, we currently do so using strcmp.
Most implementations of strcmp short-circuit and exit as soon as they
know whether two values are equal. This, however, is a problem when
we're comparing the output of HMAC, as it leaks information in the time
taken about how much of the two values match if they do indeed differ.
In our case, the nonce is used to prevent replay attacks against our
server via the embedded timestamp and replay attacks using requests from
a different server via the HMAC. Push certs, which contain the nonces,
are signed, so an attacker cannot tamper with the nonces without
breaking validation of the signature. They can, of course, create their
own signatures with invalid nonces, but they can also create their own
signatures with valid nonces, so there's nothing to be gained. Thus,
there is no security problem.
Even though it doesn't appear that there are any negative consequences
from the current technique, for safety and to encourage good practices,
let's use a constant time comparison function for nonce verification.
POSIX does not provide one, but they are easy to write.
The technique we use here is also used in NaCl and the Go standard
library and relies on the fact that bitwise or and xor are constant time
on all known architectures.
We need not be concerned about exiting early if the actual and expected
lengths differ, since the standard cryptographic assumption is that
everyone, including an attacker, knows the format of and algorithm used
in our nonces (and in any event, they have the source code and can
determine it easily). As a result, we assume everyone knows how long
our nonces should be. This philosophy is also taken by the Go standard
library and other cryptographic libraries when performing constant time
comparisons on HMAC values.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-09 23:37:30 +00:00
|
|
|
/*
|
|
|
|
* Return zero if a and b are equal up to n bytes and nonzero if they are not.
|
|
|
|
* This operation is guaranteed to run in constant time to avoid leaking data.
|
|
|
|
*/
|
|
|
|
static int constant_memequal(const char *a, const char *b, size_t n)
|
|
|
|
{
|
|
|
|
int res = 0;
|
2020-04-22 15:55:11 +00:00
|
|
|
size_t i;
|
|
|
|
|
|
|
|
for (i = 0; i < n; i++)
|
builtin/receive-pack: use constant-time comparison for HMAC value
When we're comparing a push cert nonce, we currently do so using strcmp.
Most implementations of strcmp short-circuit and exit as soon as they
know whether two values are equal. This, however, is a problem when
we're comparing the output of HMAC, as it leaks information in the time
taken about how much of the two values match if they do indeed differ.
In our case, the nonce is used to prevent replay attacks against our
server via the embedded timestamp and replay attacks using requests from
a different server via the HMAC. Push certs, which contain the nonces,
are signed, so an attacker cannot tamper with the nonces without
breaking validation of the signature. They can, of course, create their
own signatures with invalid nonces, but they can also create their own
signatures with valid nonces, so there's nothing to be gained. Thus,
there is no security problem.
Even though it doesn't appear that there are any negative consequences
from the current technique, for safety and to encourage good practices,
let's use a constant time comparison function for nonce verification.
POSIX does not provide one, but they are easy to write.
The technique we use here is also used in NaCl and the Go standard
library and relies on the fact that bitwise or and xor are constant time
on all known architectures.
We need not be concerned about exiting early if the actual and expected
lengths differ, since the standard cryptographic assumption is that
everyone, including an attacker, knows the format of and algorithm used
in our nonces (and in any event, they have the source code and can
determine it easily). As a result, we assume everyone knows how long
our nonces should be. This philosophy is also taken by the Go standard
library and other cryptographic libraries when performing constant time
comparisons on HMAC values.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-09 23:37:30 +00:00
|
|
|
res |= a[i] ^ b[i];
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
2014-08-21 23:45:30 +00:00
|
|
|
static const char *check_nonce(const char *buf, size_t len)
|
|
|
|
{
|
2017-05-09 19:23:53 +00:00
|
|
|
char *nonce = find_header(buf, len, "nonce", NULL);
|
2017-04-26 19:29:31 +00:00
|
|
|
timestamp_t stamp, ostamp;
|
signed push: allow stale nonce in stateless mode
When operating with the stateless RPC mode, we will receive a nonce
issued by another instance of us that advertised our capability and
refs some time ago. Update the logic to check received nonce to
detect this case, compute how much time has passed since the nonce
was issued and report the status with a new environment variable
GIT_PUSH_CERT_NONCE_SLOP to the hooks.
GIT_PUSH_CERT_NONCE_STATUS will report "SLOP" in such a case. The
hooks are free to decide how large a slop it is willing to accept.
Strictly speaking, the "nonce" is not really a "nonce" anymore in
the stateless RPC mode, as it will happily take any "nonce" issued
by it (which is protected by HMAC and its secret key) as long as it
is fresh enough. The degree of this security degradation, relative
to the native protocol, is about the same as the "we make sure that
the 'git push' decided to update our refs with new objects based on
the freshest observation of our refs by making sure the values they
claim the original value of the refs they ask us to update exactly
match the current state" security is loosened to accomodate the
stateless RPC mode in the existing code without this series, so
there is no need for those who are already using smart HTTP to push
to their repositories to be alarmed any more than they already are.
In addition, the server operator can set receive.certnonceslop
configuration variable to specify how stale a nonce can be (in
seconds). When this variable is set, and if the nonce received in
the certificate that passes the HMAC check was less than that many
seconds old, hooks are given "OK" in GIT_PUSH_CERT_NONCE_STATUS
(instead of "SLOP") and the received nonce value is given in
GIT_PUSH_CERT_NONCE, which makes it easier for a simple-minded
hook to check if the certificate we received is recent enough.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-05 17:46:04 +00:00
|
|
|
char *bohmac, *expect = NULL;
|
2014-08-21 23:45:30 +00:00
|
|
|
const char *retval = NONCE_BAD;
|
builtin/receive-pack: use constant-time comparison for HMAC value
When we're comparing a push cert nonce, we currently do so using strcmp.
Most implementations of strcmp short-circuit and exit as soon as they
know whether two values are equal. This, however, is a problem when
we're comparing the output of HMAC, as it leaks information in the time
taken about how much of the two values match if they do indeed differ.
In our case, the nonce is used to prevent replay attacks against our
server via the embedded timestamp and replay attacks using requests from
a different server via the HMAC. Push certs, which contain the nonces,
are signed, so an attacker cannot tamper with the nonces without
breaking validation of the signature. They can, of course, create their
own signatures with invalid nonces, but they can also create their own
signatures with valid nonces, so there's nothing to be gained. Thus,
there is no security problem.
Even though it doesn't appear that there are any negative consequences
from the current technique, for safety and to encourage good practices,
let's use a constant time comparison function for nonce verification.
POSIX does not provide one, but they are easy to write.
The technique we use here is also used in NaCl and the Go standard
library and relies on the fact that bitwise or and xor are constant time
on all known architectures.
We need not be concerned about exiting early if the actual and expected
lengths differ, since the standard cryptographic assumption is that
everyone, including an attacker, knows the format of and algorithm used
in our nonces (and in any event, they have the source code and can
determine it easily). As a result, we assume everyone knows how long
our nonces should be. This philosophy is also taken by the Go standard
library and other cryptographic libraries when performing constant time
comparisons on HMAC values.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-09 23:37:30 +00:00
|
|
|
size_t noncelen;
|
2014-08-21 23:45:30 +00:00
|
|
|
|
|
|
|
if (!nonce) {
|
|
|
|
retval = NONCE_MISSING;
|
|
|
|
goto leave;
|
|
|
|
} else if (!push_cert_nonce) {
|
|
|
|
retval = NONCE_UNSOLICITED;
|
|
|
|
goto leave;
|
|
|
|
} else if (!strcmp(push_cert_nonce, nonce)) {
|
|
|
|
retval = NONCE_OK;
|
|
|
|
goto leave;
|
|
|
|
}
|
|
|
|
|
signed push: allow stale nonce in stateless mode
When operating with the stateless RPC mode, we will receive a nonce
issued by another instance of us that advertised our capability and
refs some time ago. Update the logic to check received nonce to
detect this case, compute how much time has passed since the nonce
was issued and report the status with a new environment variable
GIT_PUSH_CERT_NONCE_SLOP to the hooks.
GIT_PUSH_CERT_NONCE_STATUS will report "SLOP" in such a case. The
hooks are free to decide how large a slop it is willing to accept.
Strictly speaking, the "nonce" is not really a "nonce" anymore in
the stateless RPC mode, as it will happily take any "nonce" issued
by it (which is protected by HMAC and its secret key) as long as it
is fresh enough. The degree of this security degradation, relative
to the native protocol, is about the same as the "we make sure that
the 'git push' decided to update our refs with new objects based on
the freshest observation of our refs by making sure the values they
claim the original value of the refs they ask us to update exactly
match the current state" security is loosened to accomodate the
stateless RPC mode in the existing code without this series, so
there is no need for those who are already using smart HTTP to push
to their repositories to be alarmed any more than they already are.
In addition, the server operator can set receive.certnonceslop
configuration variable to specify how stale a nonce can be (in
seconds). When this variable is set, and if the nonce received in
the certificate that passes the HMAC check was less than that many
seconds old, hooks are given "OK" in GIT_PUSH_CERT_NONCE_STATUS
(instead of "SLOP") and the received nonce value is given in
GIT_PUSH_CERT_NONCE, which makes it easier for a simple-minded
hook to check if the certificate we received is recent enough.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-05 17:46:04 +00:00
|
|
|
if (!stateless_rpc) {
|
|
|
|
/* returned nonce MUST match what we gave out earlier */
|
|
|
|
retval = NONCE_BAD;
|
|
|
|
goto leave;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* In stateless mode, we may be receiving a nonce issued by
|
|
|
|
* another instance of the server that serving the same
|
|
|
|
* repository, and the timestamps may not match, but the
|
|
|
|
* nonce-seed and dir should match, so we can recompute and
|
|
|
|
* report the time slop.
|
|
|
|
*
|
|
|
|
* In addition, when a nonce issued by another instance has
|
|
|
|
* timestamp within receive.certnonceslop seconds, we pretend
|
|
|
|
* as if we issued that nonce when reporting to the hook.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* nonce is concat(<seconds-since-epoch>, "-", <hmac>) */
|
|
|
|
if (*nonce <= '0' || '9' < *nonce) {
|
|
|
|
retval = NONCE_BAD;
|
|
|
|
goto leave;
|
|
|
|
}
|
2017-04-21 10:45:44 +00:00
|
|
|
stamp = parse_timestamp(nonce, &bohmac, 10);
|
signed push: allow stale nonce in stateless mode
When operating with the stateless RPC mode, we will receive a nonce
issued by another instance of us that advertised our capability and
refs some time ago. Update the logic to check received nonce to
detect this case, compute how much time has passed since the nonce
was issued and report the status with a new environment variable
GIT_PUSH_CERT_NONCE_SLOP to the hooks.
GIT_PUSH_CERT_NONCE_STATUS will report "SLOP" in such a case. The
hooks are free to decide how large a slop it is willing to accept.
Strictly speaking, the "nonce" is not really a "nonce" anymore in
the stateless RPC mode, as it will happily take any "nonce" issued
by it (which is protected by HMAC and its secret key) as long as it
is fresh enough. The degree of this security degradation, relative
to the native protocol, is about the same as the "we make sure that
the 'git push' decided to update our refs with new objects based on
the freshest observation of our refs by making sure the values they
claim the original value of the refs they ask us to update exactly
match the current state" security is loosened to accomodate the
stateless RPC mode in the existing code without this series, so
there is no need for those who are already using smart HTTP to push
to their repositories to be alarmed any more than they already are.
In addition, the server operator can set receive.certnonceslop
configuration variable to specify how stale a nonce can be (in
seconds). When this variable is set, and if the nonce received in
the certificate that passes the HMAC check was less than that many
seconds old, hooks are given "OK" in GIT_PUSH_CERT_NONCE_STATUS
(instead of "SLOP") and the received nonce value is given in
GIT_PUSH_CERT_NONCE, which makes it easier for a simple-minded
hook to check if the certificate we received is recent enough.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-05 17:46:04 +00:00
|
|
|
if (bohmac == nonce || bohmac[0] != '-') {
|
|
|
|
retval = NONCE_BAD;
|
|
|
|
goto leave;
|
|
|
|
}
|
|
|
|
|
builtin/receive-pack: use constant-time comparison for HMAC value
When we're comparing a push cert nonce, we currently do so using strcmp.
Most implementations of strcmp short-circuit and exit as soon as they
know whether two values are equal. This, however, is a problem when
we're comparing the output of HMAC, as it leaks information in the time
taken about how much of the two values match if they do indeed differ.
In our case, the nonce is used to prevent replay attacks against our
server via the embedded timestamp and replay attacks using requests from
a different server via the HMAC. Push certs, which contain the nonces,
are signed, so an attacker cannot tamper with the nonces without
breaking validation of the signature. They can, of course, create their
own signatures with invalid nonces, but they can also create their own
signatures with valid nonces, so there's nothing to be gained. Thus,
there is no security problem.
Even though it doesn't appear that there are any negative consequences
from the current technique, for safety and to encourage good practices,
let's use a constant time comparison function for nonce verification.
POSIX does not provide one, but they are easy to write.
The technique we use here is also used in NaCl and the Go standard
library and relies on the fact that bitwise or and xor are constant time
on all known architectures.
We need not be concerned about exiting early if the actual and expected
lengths differ, since the standard cryptographic assumption is that
everyone, including an attacker, knows the format of and algorithm used
in our nonces (and in any event, they have the source code and can
determine it easily). As a result, we assume everyone knows how long
our nonces should be. This philosophy is also taken by the Go standard
library and other cryptographic libraries when performing constant time
comparisons on HMAC values.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-09 23:37:30 +00:00
|
|
|
noncelen = strlen(nonce);
|
signed push: allow stale nonce in stateless mode
When operating with the stateless RPC mode, we will receive a nonce
issued by another instance of us that advertised our capability and
refs some time ago. Update the logic to check received nonce to
detect this case, compute how much time has passed since the nonce
was issued and report the status with a new environment variable
GIT_PUSH_CERT_NONCE_SLOP to the hooks.
GIT_PUSH_CERT_NONCE_STATUS will report "SLOP" in such a case. The
hooks are free to decide how large a slop it is willing to accept.
Strictly speaking, the "nonce" is not really a "nonce" anymore in
the stateless RPC mode, as it will happily take any "nonce" issued
by it (which is protected by HMAC and its secret key) as long as it
is fresh enough. The degree of this security degradation, relative
to the native protocol, is about the same as the "we make sure that
the 'git push' decided to update our refs with new objects based on
the freshest observation of our refs by making sure the values they
claim the original value of the refs they ask us to update exactly
match the current state" security is loosened to accomodate the
stateless RPC mode in the existing code without this series, so
there is no need for those who are already using smart HTTP to push
to their repositories to be alarmed any more than they already are.
In addition, the server operator can set receive.certnonceslop
configuration variable to specify how stale a nonce can be (in
seconds). When this variable is set, and if the nonce received in
the certificate that passes the HMAC check was less than that many
seconds old, hooks are given "OK" in GIT_PUSH_CERT_NONCE_STATUS
(instead of "SLOP") and the received nonce value is given in
GIT_PUSH_CERT_NONCE, which makes it easier for a simple-minded
hook to check if the certificate we received is recent enough.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-05 17:46:04 +00:00
|
|
|
expect = prepare_push_cert_nonce(service_dir, stamp);
|
builtin/receive-pack: use constant-time comparison for HMAC value
When we're comparing a push cert nonce, we currently do so using strcmp.
Most implementations of strcmp short-circuit and exit as soon as they
know whether two values are equal. This, however, is a problem when
we're comparing the output of HMAC, as it leaks information in the time
taken about how much of the two values match if they do indeed differ.
In our case, the nonce is used to prevent replay attacks against our
server via the embedded timestamp and replay attacks using requests from
a different server via the HMAC. Push certs, which contain the nonces,
are signed, so an attacker cannot tamper with the nonces without
breaking validation of the signature. They can, of course, create their
own signatures with invalid nonces, but they can also create their own
signatures with valid nonces, so there's nothing to be gained. Thus,
there is no security problem.
Even though it doesn't appear that there are any negative consequences
from the current technique, for safety and to encourage good practices,
let's use a constant time comparison function for nonce verification.
POSIX does not provide one, but they are easy to write.
The technique we use here is also used in NaCl and the Go standard
library and relies on the fact that bitwise or and xor are constant time
on all known architectures.
We need not be concerned about exiting early if the actual and expected
lengths differ, since the standard cryptographic assumption is that
everyone, including an attacker, knows the format of and algorithm used
in our nonces (and in any event, they have the source code and can
determine it easily). As a result, we assume everyone knows how long
our nonces should be. This philosophy is also taken by the Go standard
library and other cryptographic libraries when performing constant time
comparisons on HMAC values.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-09 23:37:30 +00:00
|
|
|
if (noncelen != strlen(expect)) {
|
|
|
|
/* This is not even the right size. */
|
|
|
|
retval = NONCE_BAD;
|
|
|
|
goto leave;
|
|
|
|
}
|
|
|
|
if (constant_memequal(expect, nonce, noncelen)) {
|
signed push: allow stale nonce in stateless mode
When operating with the stateless RPC mode, we will receive a nonce
issued by another instance of us that advertised our capability and
refs some time ago. Update the logic to check received nonce to
detect this case, compute how much time has passed since the nonce
was issued and report the status with a new environment variable
GIT_PUSH_CERT_NONCE_SLOP to the hooks.
GIT_PUSH_CERT_NONCE_STATUS will report "SLOP" in such a case. The
hooks are free to decide how large a slop it is willing to accept.
Strictly speaking, the "nonce" is not really a "nonce" anymore in
the stateless RPC mode, as it will happily take any "nonce" issued
by it (which is protected by HMAC and its secret key) as long as it
is fresh enough. The degree of this security degradation, relative
to the native protocol, is about the same as the "we make sure that
the 'git push' decided to update our refs with new objects based on
the freshest observation of our refs by making sure the values they
claim the original value of the refs they ask us to update exactly
match the current state" security is loosened to accomodate the
stateless RPC mode in the existing code without this series, so
there is no need for those who are already using smart HTTP to push
to their repositories to be alarmed any more than they already are.
In addition, the server operator can set receive.certnonceslop
configuration variable to specify how stale a nonce can be (in
seconds). When this variable is set, and if the nonce received in
the certificate that passes the HMAC check was less than that many
seconds old, hooks are given "OK" in GIT_PUSH_CERT_NONCE_STATUS
(instead of "SLOP") and the received nonce value is given in
GIT_PUSH_CERT_NONCE, which makes it easier for a simple-minded
hook to check if the certificate we received is recent enough.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-05 17:46:04 +00:00
|
|
|
/* Not what we would have signed earlier */
|
|
|
|
retval = NONCE_BAD;
|
|
|
|
goto leave;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* By how many seconds is this nonce stale? Negative value
|
|
|
|
* would mean it was issued by another server with its clock
|
|
|
|
* skewed in the future.
|
|
|
|
*/
|
2017-04-21 10:45:44 +00:00
|
|
|
ostamp = parse_timestamp(push_cert_nonce, NULL, 10);
|
signed push: allow stale nonce in stateless mode
When operating with the stateless RPC mode, we will receive a nonce
issued by another instance of us that advertised our capability and
refs some time ago. Update the logic to check received nonce to
detect this case, compute how much time has passed since the nonce
was issued and report the status with a new environment variable
GIT_PUSH_CERT_NONCE_SLOP to the hooks.
GIT_PUSH_CERT_NONCE_STATUS will report "SLOP" in such a case. The
hooks are free to decide how large a slop it is willing to accept.
Strictly speaking, the "nonce" is not really a "nonce" anymore in
the stateless RPC mode, as it will happily take any "nonce" issued
by it (which is protected by HMAC and its secret key) as long as it
is fresh enough. The degree of this security degradation, relative
to the native protocol, is about the same as the "we make sure that
the 'git push' decided to update our refs with new objects based on
the freshest observation of our refs by making sure the values they
claim the original value of the refs they ask us to update exactly
match the current state" security is loosened to accomodate the
stateless RPC mode in the existing code without this series, so
there is no need for those who are already using smart HTTP to push
to their repositories to be alarmed any more than they already are.
In addition, the server operator can set receive.certnonceslop
configuration variable to specify how stale a nonce can be (in
seconds). When this variable is set, and if the nonce received in
the certificate that passes the HMAC check was less than that many
seconds old, hooks are given "OK" in GIT_PUSH_CERT_NONCE_STATUS
(instead of "SLOP") and the received nonce value is given in
GIT_PUSH_CERT_NONCE, which makes it easier for a simple-minded
hook to check if the certificate we received is recent enough.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-05 17:46:04 +00:00
|
|
|
nonce_stamp_slop = (long)ostamp - (long)stamp;
|
|
|
|
|
|
|
|
if (nonce_stamp_slop_limit &&
|
2014-11-15 13:27:21 +00:00
|
|
|
labs(nonce_stamp_slop) <= nonce_stamp_slop_limit) {
|
signed push: allow stale nonce in stateless mode
When operating with the stateless RPC mode, we will receive a nonce
issued by another instance of us that advertised our capability and
refs some time ago. Update the logic to check received nonce to
detect this case, compute how much time has passed since the nonce
was issued and report the status with a new environment variable
GIT_PUSH_CERT_NONCE_SLOP to the hooks.
GIT_PUSH_CERT_NONCE_STATUS will report "SLOP" in such a case. The
hooks are free to decide how large a slop it is willing to accept.
Strictly speaking, the "nonce" is not really a "nonce" anymore in
the stateless RPC mode, as it will happily take any "nonce" issued
by it (which is protected by HMAC and its secret key) as long as it
is fresh enough. The degree of this security degradation, relative
to the native protocol, is about the same as the "we make sure that
the 'git push' decided to update our refs with new objects based on
the freshest observation of our refs by making sure the values they
claim the original value of the refs they ask us to update exactly
match the current state" security is loosened to accomodate the
stateless RPC mode in the existing code without this series, so
there is no need for those who are already using smart HTTP to push
to their repositories to be alarmed any more than they already are.
In addition, the server operator can set receive.certnonceslop
configuration variable to specify how stale a nonce can be (in
seconds). When this variable is set, and if the nonce received in
the certificate that passes the HMAC check was less than that many
seconds old, hooks are given "OK" in GIT_PUSH_CERT_NONCE_STATUS
(instead of "SLOP") and the received nonce value is given in
GIT_PUSH_CERT_NONCE, which makes it easier for a simple-minded
hook to check if the certificate we received is recent enough.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-05 17:46:04 +00:00
|
|
|
/*
|
|
|
|
* Pretend as if the received nonce (which passes the
|
|
|
|
* HMAC check, so it is not a forged by third-party)
|
|
|
|
* is what we issued.
|
|
|
|
*/
|
|
|
|
free((void *)push_cert_nonce);
|
|
|
|
push_cert_nonce = xstrdup(nonce);
|
|
|
|
retval = NONCE_OK;
|
|
|
|
} else {
|
|
|
|
retval = NONCE_SLOP;
|
|
|
|
}
|
2014-08-21 23:45:30 +00:00
|
|
|
|
|
|
|
leave:
|
|
|
|
free(nonce);
|
signed push: allow stale nonce in stateless mode
When operating with the stateless RPC mode, we will receive a nonce
issued by another instance of us that advertised our capability and
refs some time ago. Update the logic to check received nonce to
detect this case, compute how much time has passed since the nonce
was issued and report the status with a new environment variable
GIT_PUSH_CERT_NONCE_SLOP to the hooks.
GIT_PUSH_CERT_NONCE_STATUS will report "SLOP" in such a case. The
hooks are free to decide how large a slop it is willing to accept.
Strictly speaking, the "nonce" is not really a "nonce" anymore in
the stateless RPC mode, as it will happily take any "nonce" issued
by it (which is protected by HMAC and its secret key) as long as it
is fresh enough. The degree of this security degradation, relative
to the native protocol, is about the same as the "we make sure that
the 'git push' decided to update our refs with new objects based on
the freshest observation of our refs by making sure the values they
claim the original value of the refs they ask us to update exactly
match the current state" security is loosened to accomodate the
stateless RPC mode in the existing code without this series, so
there is no need for those who are already using smart HTTP to push
to their repositories to be alarmed any more than they already are.
In addition, the server operator can set receive.certnonceslop
configuration variable to specify how stale a nonce can be (in
seconds). When this variable is set, and if the nonce received in
the certificate that passes the HMAC check was less than that many
seconds old, hooks are given "OK" in GIT_PUSH_CERT_NONCE_STATUS
(instead of "SLOP") and the received nonce value is given in
GIT_PUSH_CERT_NONCE, which makes it easier for a simple-minded
hook to check if the certificate we received is recent enough.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-05 17:46:04 +00:00
|
|
|
free(expect);
|
2014-08-21 23:45:30 +00:00
|
|
|
return retval;
|
|
|
|
}
|
|
|
|
|
2017-05-09 19:23:53 +00:00
|
|
|
/*
|
|
|
|
* Return 1 if there is no push_cert or if the push options in push_cert are
|
|
|
|
* the same as those in the argument; 0 otherwise.
|
|
|
|
*/
|
|
|
|
static int check_cert_push_options(const struct string_list *push_options)
|
|
|
|
{
|
|
|
|
const char *buf = push_cert.buf;
|
|
|
|
int len = push_cert.len;
|
|
|
|
|
|
|
|
char *option;
|
|
|
|
const char *next_line;
|
|
|
|
int options_seen = 0;
|
|
|
|
|
|
|
|
int retval = 1;
|
|
|
|
|
|
|
|
if (!len)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
while ((option = find_header(buf, len, "push-option", &next_line))) {
|
|
|
|
len -= (next_line - buf);
|
|
|
|
buf = next_line;
|
|
|
|
options_seen++;
|
|
|
|
if (options_seen > push_options->nr
|
|
|
|
|| strcmp(option,
|
|
|
|
push_options->items[options_seen - 1].string)) {
|
|
|
|
retval = 0;
|
|
|
|
goto leave;
|
|
|
|
}
|
|
|
|
free(option);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (options_seen != push_options->nr)
|
|
|
|
retval = 0;
|
|
|
|
|
|
|
|
leave:
|
|
|
|
free(option);
|
|
|
|
return retval;
|
|
|
|
}
|
|
|
|
|
push: the beginning of "git push --signed"
While signed tags and commits assert that the objects thusly signed
came from you, who signed these objects, there is not a good way to
assert that you wanted to have a particular object at the tip of a
particular branch. My signing v2.0.1 tag only means I want to call
the version v2.0.1, and it does not mean I want to push it out to my
'master' branch---it is likely that I only want it in 'maint', so
the signature on the object alone is insufficient.
The only assurance to you that 'maint' points at what I wanted to
place there comes from your trust on the hosting site and my
authentication with it, which cannot easily audited later.
Introduce a mechanism that allows you to sign a "push certificate"
(for the lack of better name) every time you push, asserting that
what object you are pushing to update which ref that used to point
at what other object. Think of it as a cryptographic protection for
ref updates, similar to signed tags/commits but working on an
orthogonal axis.
The basic flow based on this mechanism goes like this:
1. You push out your work with "git push --signed".
2. The sending side learns where the remote refs are as usual,
together with what protocol extension the receiving end
supports. If the receiving end does not advertise the protocol
extension "push-cert", an attempt to "git push --signed" fails.
Otherwise, a text file, that looks like the following, is
prepared in core:
certificate version 0.1
pusher Junio C Hamano <gitster@pobox.com> 1315427886 -0700
7339ca65... 21580ecb... refs/heads/master
3793ac56... 12850bec... refs/heads/next
The file begins with a few header lines, which may grow as we
gain more experience. The 'pusher' header records the name of
the signer (the value of user.signingkey configuration variable,
falling back to GIT_COMMITTER_{NAME|EMAIL}) and the time of the
certificate generation. After the header, a blank line follows,
followed by a copy of the protocol message lines.
Each line shows the old and the new object name at the tip of
the ref this push tries to update, in the way identical to how
the underlying "git push" protocol exchange tells the ref
updates to the receiving end (by recording the "old" object
name, the push certificate also protects against replaying). It
is expected that new command packet types other than the
old-new-refname kind will be included in push certificate in the
same way as would appear in the plain vanilla command packets in
unsigned pushes.
The user then is asked to sign this push certificate using GPG,
formatted in a way similar to how signed tag objects are signed,
and the result is sent to the other side (i.e. receive-pack).
In the protocol exchange, this step comes immediately before the
sender tells what the result of the push should be, which in
turn comes before it sends the pack data.
3. When the receiving end sees a push certificate, the certificate
is written out as a blob. The pre-receive hook can learn about
the certificate by checking GIT_PUSH_CERT environment variable,
which, if present, tells the object name of this blob, and make
the decision to allow or reject this push. Additionally, the
post-receive hook can also look at the certificate, which may be
a good place to log all the received certificates for later
audits.
Because a push certificate carry the same information as the usual
command packets in the protocol exchange, we can omit the latter
when a push certificate is in use and reduce the protocol overhead.
This however is not included in this patch to make it easier to
review (in other words, the series at this step should never be
released without the remainder of the series, as it implements an
interim protocol that will be incompatible with the final one).
As such, the documentation update for the protocol is left out of
this step.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-12 18:17:07 +00:00
|
|
|
static void prepare_push_cert_sha1(struct child_process *proc)
|
|
|
|
{
|
|
|
|
static int already_done;
|
|
|
|
|
|
|
|
if (!push_cert.len)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (!already_done) {
|
2014-08-14 22:59:21 +00:00
|
|
|
int bogs /* beginning_of_gpg_sig */;
|
|
|
|
|
push: the beginning of "git push --signed"
While signed tags and commits assert that the objects thusly signed
came from you, who signed these objects, there is not a good way to
assert that you wanted to have a particular object at the tip of a
particular branch. My signing v2.0.1 tag only means I want to call
the version v2.0.1, and it does not mean I want to push it out to my
'master' branch---it is likely that I only want it in 'maint', so
the signature on the object alone is insufficient.
The only assurance to you that 'maint' points at what I wanted to
place there comes from your trust on the hosting site and my
authentication with it, which cannot easily audited later.
Introduce a mechanism that allows you to sign a "push certificate"
(for the lack of better name) every time you push, asserting that
what object you are pushing to update which ref that used to point
at what other object. Think of it as a cryptographic protection for
ref updates, similar to signed tags/commits but working on an
orthogonal axis.
The basic flow based on this mechanism goes like this:
1. You push out your work with "git push --signed".
2. The sending side learns where the remote refs are as usual,
together with what protocol extension the receiving end
supports. If the receiving end does not advertise the protocol
extension "push-cert", an attempt to "git push --signed" fails.
Otherwise, a text file, that looks like the following, is
prepared in core:
certificate version 0.1
pusher Junio C Hamano <gitster@pobox.com> 1315427886 -0700
7339ca65... 21580ecb... refs/heads/master
3793ac56... 12850bec... refs/heads/next
The file begins with a few header lines, which may grow as we
gain more experience. The 'pusher' header records the name of
the signer (the value of user.signingkey configuration variable,
falling back to GIT_COMMITTER_{NAME|EMAIL}) and the time of the
certificate generation. After the header, a blank line follows,
followed by a copy of the protocol message lines.
Each line shows the old and the new object name at the tip of
the ref this push tries to update, in the way identical to how
the underlying "git push" protocol exchange tells the ref
updates to the receiving end (by recording the "old" object
name, the push certificate also protects against replaying). It
is expected that new command packet types other than the
old-new-refname kind will be included in push certificate in the
same way as would appear in the plain vanilla command packets in
unsigned pushes.
The user then is asked to sign this push certificate using GPG,
formatted in a way similar to how signed tag objects are signed,
and the result is sent to the other side (i.e. receive-pack).
In the protocol exchange, this step comes immediately before the
sender tells what the result of the push should be, which in
turn comes before it sends the pack data.
3. When the receiving end sees a push certificate, the certificate
is written out as a blob. The pre-receive hook can learn about
the certificate by checking GIT_PUSH_CERT environment variable,
which, if present, tells the object name of this blob, and make
the decision to allow or reject this push. Additionally, the
post-receive hook can also look at the certificate, which may be
a good place to log all the received certificates for later
audits.
Because a push certificate carry the same information as the usual
command packets in the protocol exchange, we can omit the latter
when a push certificate is in use and reduce the protocol overhead.
This however is not included in this patch to make it easier to
review (in other words, the series at this step should never be
released without the remainder of the series, as it implements an
interim protocol that will be incompatible with the final one).
As such, the documentation update for the protocol is left out of
this step.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-12 18:17:07 +00:00
|
|
|
already_done = 1;
|
2022-02-04 23:48:26 +00:00
|
|
|
if (write_object_file(push_cert.buf, push_cert.len, OBJ_BLOB,
|
2018-01-28 00:13:19 +00:00
|
|
|
&push_cert_oid))
|
|
|
|
oidclr(&push_cert_oid);
|
2014-08-14 22:59:21 +00:00
|
|
|
|
|
|
|
memset(&sigcheck, '\0', sizeof(sigcheck));
|
|
|
|
|
2021-02-11 02:08:03 +00:00
|
|
|
bogs = parse_signed_buffer(push_cert.buf, push_cert.len);
|
2021-12-09 08:52:43 +00:00
|
|
|
sigcheck.payload = xmemdupz(push_cert.buf, bogs);
|
|
|
|
sigcheck.payload_len = bogs;
|
|
|
|
check_signature(&sigcheck, push_cert.buf + bogs,
|
|
|
|
push_cert.len - bogs);
|
2014-08-14 22:59:21 +00:00
|
|
|
|
2014-08-21 23:45:30 +00:00
|
|
|
nonce_status = check_nonce(push_cert.buf, bogs);
|
push: the beginning of "git push --signed"
While signed tags and commits assert that the objects thusly signed
came from you, who signed these objects, there is not a good way to
assert that you wanted to have a particular object at the tip of a
particular branch. My signing v2.0.1 tag only means I want to call
the version v2.0.1, and it does not mean I want to push it out to my
'master' branch---it is likely that I only want it in 'maint', so
the signature on the object alone is insufficient.
The only assurance to you that 'maint' points at what I wanted to
place there comes from your trust on the hosting site and my
authentication with it, which cannot easily audited later.
Introduce a mechanism that allows you to sign a "push certificate"
(for the lack of better name) every time you push, asserting that
what object you are pushing to update which ref that used to point
at what other object. Think of it as a cryptographic protection for
ref updates, similar to signed tags/commits but working on an
orthogonal axis.
The basic flow based on this mechanism goes like this:
1. You push out your work with "git push --signed".
2. The sending side learns where the remote refs are as usual,
together with what protocol extension the receiving end
supports. If the receiving end does not advertise the protocol
extension "push-cert", an attempt to "git push --signed" fails.
Otherwise, a text file, that looks like the following, is
prepared in core:
certificate version 0.1
pusher Junio C Hamano <gitster@pobox.com> 1315427886 -0700
7339ca65... 21580ecb... refs/heads/master
3793ac56... 12850bec... refs/heads/next
The file begins with a few header lines, which may grow as we
gain more experience. The 'pusher' header records the name of
the signer (the value of user.signingkey configuration variable,
falling back to GIT_COMMITTER_{NAME|EMAIL}) and the time of the
certificate generation. After the header, a blank line follows,
followed by a copy of the protocol message lines.
Each line shows the old and the new object name at the tip of
the ref this push tries to update, in the way identical to how
the underlying "git push" protocol exchange tells the ref
updates to the receiving end (by recording the "old" object
name, the push certificate also protects against replaying). It
is expected that new command packet types other than the
old-new-refname kind will be included in push certificate in the
same way as would appear in the plain vanilla command packets in
unsigned pushes.
The user then is asked to sign this push certificate using GPG,
formatted in a way similar to how signed tag objects are signed,
and the result is sent to the other side (i.e. receive-pack).
In the protocol exchange, this step comes immediately before the
sender tells what the result of the push should be, which in
turn comes before it sends the pack data.
3. When the receiving end sees a push certificate, the certificate
is written out as a blob. The pre-receive hook can learn about
the certificate by checking GIT_PUSH_CERT environment variable,
which, if present, tells the object name of this blob, and make
the decision to allow or reject this push. Additionally, the
post-receive hook can also look at the certificate, which may be
a good place to log all the received certificates for later
audits.
Because a push certificate carry the same information as the usual
command packets in the protocol exchange, we can omit the latter
when a push certificate is in use and reduce the protocol overhead.
This however is not included in this patch to make it easier to
review (in other words, the series at this step should never be
released without the remainder of the series, as it implements an
interim protocol that will be incompatible with the final one).
As such, the documentation update for the protocol is left out of
this step.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-12 18:17:07 +00:00
|
|
|
}
|
2018-01-28 00:13:19 +00:00
|
|
|
if (!is_null_oid(&push_cert_oid)) {
|
2022-06-02 09:09:50 +00:00
|
|
|
strvec_pushf(&proc->env, "GIT_PUSH_CERT=%s",
|
strvec: fix indentation in renamed calls
Code which split an argv_array call across multiple lines, like:
argv_array_pushl(&args, "one argument",
"another argument", "and more",
NULL);
was recently mechanically renamed to use strvec, which results in
mis-matched indentation like:
strvec_pushl(&args, "one argument",
"another argument", "and more",
NULL);
Let's fix these up to align the arguments with the opening paren. I did
this manually by sifting through the results of:
git jump grep 'strvec_.*,$'
and liberally applying my editor's auto-format. Most of the changes are
of the form shown above, though I also normalized a few that had
originally used a single-tab indentation (rather than our usual style of
aligning with the open paren). I also rewrapped a couple of obvious
cases (e.g., where previously too-long lines became short enough to fit
on one), but I wasn't aggressive about it. In cases broken to three or
more lines, the grouping of arguments is sometimes meaningful, and it
wasn't worth my time or reviewer time to ponder each case individually.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-28 20:26:31 +00:00
|
|
|
oid_to_hex(&push_cert_oid));
|
2022-06-02 09:09:50 +00:00
|
|
|
strvec_pushf(&proc->env, "GIT_PUSH_CERT_SIGNER=%s",
|
strvec: fix indentation in renamed calls
Code which split an argv_array call across multiple lines, like:
argv_array_pushl(&args, "one argument",
"another argument", "and more",
NULL);
was recently mechanically renamed to use strvec, which results in
mis-matched indentation like:
strvec_pushl(&args, "one argument",
"another argument", "and more",
NULL);
Let's fix these up to align the arguments with the opening paren. I did
this manually by sifting through the results of:
git jump grep 'strvec_.*,$'
and liberally applying my editor's auto-format. Most of the changes are
of the form shown above, though I also normalized a few that had
originally used a single-tab indentation (rather than our usual style of
aligning with the open paren). I also rewrapped a couple of obvious
cases (e.g., where previously too-long lines became short enough to fit
on one), but I wasn't aggressive about it. In cases broken to three or
more lines, the grouping of arguments is sometimes meaningful, and it
wasn't worth my time or reviewer time to ponder each case individually.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-28 20:26:31 +00:00
|
|
|
sigcheck.signer ? sigcheck.signer : "");
|
2022-06-02 09:09:50 +00:00
|
|
|
strvec_pushf(&proc->env, "GIT_PUSH_CERT_KEY=%s",
|
strvec: fix indentation in renamed calls
Code which split an argv_array call across multiple lines, like:
argv_array_pushl(&args, "one argument",
"another argument", "and more",
NULL);
was recently mechanically renamed to use strvec, which results in
mis-matched indentation like:
strvec_pushl(&args, "one argument",
"another argument", "and more",
NULL);
Let's fix these up to align the arguments with the opening paren. I did
this manually by sifting through the results of:
git jump grep 'strvec_.*,$'
and liberally applying my editor's auto-format. Most of the changes are
of the form shown above, though I also normalized a few that had
originally used a single-tab indentation (rather than our usual style of
aligning with the open paren). I also rewrapped a couple of obvious
cases (e.g., where previously too-long lines became short enough to fit
on one), but I wasn't aggressive about it. In cases broken to three or
more lines, the grouping of arguments is sometimes meaningful, and it
wasn't worth my time or reviewer time to ponder each case individually.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-28 20:26:31 +00:00
|
|
|
sigcheck.key ? sigcheck.key : "");
|
2022-06-02 09:09:50 +00:00
|
|
|
strvec_pushf(&proc->env, "GIT_PUSH_CERT_STATUS=%c",
|
strvec: fix indentation in renamed calls
Code which split an argv_array call across multiple lines, like:
argv_array_pushl(&args, "one argument",
"another argument", "and more",
NULL);
was recently mechanically renamed to use strvec, which results in
mis-matched indentation like:
strvec_pushl(&args, "one argument",
"another argument", "and more",
NULL);
Let's fix these up to align the arguments with the opening paren. I did
this manually by sifting through the results of:
git jump grep 'strvec_.*,$'
and liberally applying my editor's auto-format. Most of the changes are
of the form shown above, though I also normalized a few that had
originally used a single-tab indentation (rather than our usual style of
aligning with the open paren). I also rewrapped a couple of obvious
cases (e.g., where previously too-long lines became short enough to fit
on one), but I wasn't aggressive about it. In cases broken to three or
more lines, the grouping of arguments is sometimes meaningful, and it
wasn't worth my time or reviewer time to ponder each case individually.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-28 20:26:31 +00:00
|
|
|
sigcheck.result);
|
2014-08-21 23:45:30 +00:00
|
|
|
if (push_cert_nonce) {
|
2022-06-02 09:09:50 +00:00
|
|
|
strvec_pushf(&proc->env,
|
strvec: fix indentation in renamed calls
Code which split an argv_array call across multiple lines, like:
argv_array_pushl(&args, "one argument",
"another argument", "and more",
NULL);
was recently mechanically renamed to use strvec, which results in
mis-matched indentation like:
strvec_pushl(&args, "one argument",
"another argument", "and more",
NULL);
Let's fix these up to align the arguments with the opening paren. I did
this manually by sifting through the results of:
git jump grep 'strvec_.*,$'
and liberally applying my editor's auto-format. Most of the changes are
of the form shown above, though I also normalized a few that had
originally used a single-tab indentation (rather than our usual style of
aligning with the open paren). I also rewrapped a couple of obvious
cases (e.g., where previously too-long lines became short enough to fit
on one), but I wasn't aggressive about it. In cases broken to three or
more lines, the grouping of arguments is sometimes meaningful, and it
wasn't worth my time or reviewer time to ponder each case individually.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-28 20:26:31 +00:00
|
|
|
"GIT_PUSH_CERT_NONCE=%s",
|
|
|
|
push_cert_nonce);
|
2022-06-02 09:09:50 +00:00
|
|
|
strvec_pushf(&proc->env,
|
strvec: fix indentation in renamed calls
Code which split an argv_array call across multiple lines, like:
argv_array_pushl(&args, "one argument",
"another argument", "and more",
NULL);
was recently mechanically renamed to use strvec, which results in
mis-matched indentation like:
strvec_pushl(&args, "one argument",
"another argument", "and more",
NULL);
Let's fix these up to align the arguments with the opening paren. I did
this manually by sifting through the results of:
git jump grep 'strvec_.*,$'
and liberally applying my editor's auto-format. Most of the changes are
of the form shown above, though I also normalized a few that had
originally used a single-tab indentation (rather than our usual style of
aligning with the open paren). I also rewrapped a couple of obvious
cases (e.g., where previously too-long lines became short enough to fit
on one), but I wasn't aggressive about it. In cases broken to three or
more lines, the grouping of arguments is sometimes meaningful, and it
wasn't worth my time or reviewer time to ponder each case individually.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-28 20:26:31 +00:00
|
|
|
"GIT_PUSH_CERT_NONCE_STATUS=%s",
|
|
|
|
nonce_status);
|
signed push: allow stale nonce in stateless mode
When operating with the stateless RPC mode, we will receive a nonce
issued by another instance of us that advertised our capability and
refs some time ago. Update the logic to check received nonce to
detect this case, compute how much time has passed since the nonce
was issued and report the status with a new environment variable
GIT_PUSH_CERT_NONCE_SLOP to the hooks.
GIT_PUSH_CERT_NONCE_STATUS will report "SLOP" in such a case. The
hooks are free to decide how large a slop it is willing to accept.
Strictly speaking, the "nonce" is not really a "nonce" anymore in
the stateless RPC mode, as it will happily take any "nonce" issued
by it (which is protected by HMAC and its secret key) as long as it
is fresh enough. The degree of this security degradation, relative
to the native protocol, is about the same as the "we make sure that
the 'git push' decided to update our refs with new objects based on
the freshest observation of our refs by making sure the values they
claim the original value of the refs they ask us to update exactly
match the current state" security is loosened to accomodate the
stateless RPC mode in the existing code without this series, so
there is no need for those who are already using smart HTTP to push
to their repositories to be alarmed any more than they already are.
In addition, the server operator can set receive.certnonceslop
configuration variable to specify how stale a nonce can be (in
seconds). When this variable is set, and if the nonce received in
the certificate that passes the HMAC check was less than that many
seconds old, hooks are given "OK" in GIT_PUSH_CERT_NONCE_STATUS
(instead of "SLOP") and the received nonce value is given in
GIT_PUSH_CERT_NONCE, which makes it easier for a simple-minded
hook to check if the certificate we received is recent enough.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-05 17:46:04 +00:00
|
|
|
if (nonce_status == NONCE_SLOP)
|
2022-06-02 09:09:50 +00:00
|
|
|
strvec_pushf(&proc->env,
|
strvec: fix indentation in renamed calls
Code which split an argv_array call across multiple lines, like:
argv_array_pushl(&args, "one argument",
"another argument", "and more",
NULL);
was recently mechanically renamed to use strvec, which results in
mis-matched indentation like:
strvec_pushl(&args, "one argument",
"another argument", "and more",
NULL);
Let's fix these up to align the arguments with the opening paren. I did
this manually by sifting through the results of:
git jump grep 'strvec_.*,$'
and liberally applying my editor's auto-format. Most of the changes are
of the form shown above, though I also normalized a few that had
originally used a single-tab indentation (rather than our usual style of
aligning with the open paren). I also rewrapped a couple of obvious
cases (e.g., where previously too-long lines became short enough to fit
on one), but I wasn't aggressive about it. In cases broken to three or
more lines, the grouping of arguments is sometimes meaningful, and it
wasn't worth my time or reviewer time to ponder each case individually.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-28 20:26:31 +00:00
|
|
|
"GIT_PUSH_CERT_NONCE_SLOP=%ld",
|
|
|
|
nonce_stamp_slop);
|
2014-08-21 23:45:30 +00:00
|
|
|
}
|
push: the beginning of "git push --signed"
While signed tags and commits assert that the objects thusly signed
came from you, who signed these objects, there is not a good way to
assert that you wanted to have a particular object at the tip of a
particular branch. My signing v2.0.1 tag only means I want to call
the version v2.0.1, and it does not mean I want to push it out to my
'master' branch---it is likely that I only want it in 'maint', so
the signature on the object alone is insufficient.
The only assurance to you that 'maint' points at what I wanted to
place there comes from your trust on the hosting site and my
authentication with it, which cannot easily audited later.
Introduce a mechanism that allows you to sign a "push certificate"
(for the lack of better name) every time you push, asserting that
what object you are pushing to update which ref that used to point
at what other object. Think of it as a cryptographic protection for
ref updates, similar to signed tags/commits but working on an
orthogonal axis.
The basic flow based on this mechanism goes like this:
1. You push out your work with "git push --signed".
2. The sending side learns where the remote refs are as usual,
together with what protocol extension the receiving end
supports. If the receiving end does not advertise the protocol
extension "push-cert", an attempt to "git push --signed" fails.
Otherwise, a text file, that looks like the following, is
prepared in core:
certificate version 0.1
pusher Junio C Hamano <gitster@pobox.com> 1315427886 -0700
7339ca65... 21580ecb... refs/heads/master
3793ac56... 12850bec... refs/heads/next
The file begins with a few header lines, which may grow as we
gain more experience. The 'pusher' header records the name of
the signer (the value of user.signingkey configuration variable,
falling back to GIT_COMMITTER_{NAME|EMAIL}) and the time of the
certificate generation. After the header, a blank line follows,
followed by a copy of the protocol message lines.
Each line shows the old and the new object name at the tip of
the ref this push tries to update, in the way identical to how
the underlying "git push" protocol exchange tells the ref
updates to the receiving end (by recording the "old" object
name, the push certificate also protects against replaying). It
is expected that new command packet types other than the
old-new-refname kind will be included in push certificate in the
same way as would appear in the plain vanilla command packets in
unsigned pushes.
The user then is asked to sign this push certificate using GPG,
formatted in a way similar to how signed tag objects are signed,
and the result is sent to the other side (i.e. receive-pack).
In the protocol exchange, this step comes immediately before the
sender tells what the result of the push should be, which in
turn comes before it sends the pack data.
3. When the receiving end sees a push certificate, the certificate
is written out as a blob. The pre-receive hook can learn about
the certificate by checking GIT_PUSH_CERT environment variable,
which, if present, tells the object name of this blob, and make
the decision to allow or reject this push. Additionally, the
post-receive hook can also look at the certificate, which may be
a good place to log all the received certificates for later
audits.
Because a push certificate carry the same information as the usual
command packets in the protocol exchange, we can omit the latter
when a push certificate is in use and reduce the protocol overhead.
This however is not included in this patch to make it easier to
review (in other words, the series at this step should never be
released without the remainder of the series, as it implements an
interim protocol that will be incompatible with the final one).
As such, the documentation update for the protocol is left out of
this step.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-12 18:17:07 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
push options: {pre,post}-receive hook learns about push options
The environment variable GIT_PUSH_OPTION_COUNT is set to the number of
push options sent, and GIT_PUSH_OPTION_{0,1,..} is set to the transmitted
option.
The code is not executed as the push options are set to NULL, nor is the
new capability advertised.
There was some discussion back and forth how to present these push options
to the user as there are some ways to do it:
Keep all options in one environment variable
============================================
+ easiest way to implement in Git
- This would make things hard to parse correctly in the hook.
Put the options in files instead,
filenames are in GIT_PUSH_OPTION_FILES
======================================
+ After a discussion about environment variables and shells, we may not
want to put user data into an environment variable (see [1] for example).
+ We could transmit binaries, i.e. we're not bound to C strings as
we are when using environment variables to the user.
+ Maybe easier to parse than constructing environment variable names
GIT_PUSH_OPTION_{0,1,..} yourself
- cleanup of the temporary files is hard to do reliably
- we have race conditions with multiple clients pushing, hence we'd need
to use mkstemp. That's not too bad, but still.
Use environment variables, but restrict to key/value pairs
==========================================================
(When the user pushes a push option `foo=bar`, we'd
GIT_PUSH_OPTION_foo=bar)
+ very easy to parse for a simple model of push options
- it's not sufficient for more elaborate models, e.g.
it doesn't allow doubles (e.g. cc=reviewer@email)
Present the options in different environment variables
======================================================
(This is implemented)
* harder to parse as a user, but we have a sample hook for that.
- doesn't allow binary files
+ allows the same option twice, i.e. is not restrictive about
options, except for binary files.
+ doesn't clutter a remote directory with (possibly stale)
temporary files
As we first want to focus on getting simple strings to work
reliably, we go with the last option for now. If we want to
do transmission of binaries later, we can just attach a
'side-channel', e.g. "any push option that contains a '\0' is
put into a file instead of the environment variable and we'd
have new GIT_PUSH_OPTION_FILES, GIT_PUSH_OPTION_FILENAME_{0,1,..}
environment variables".
[1] 'Shellshock' https://lwn.net/Articles/614218/
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-14 21:49:45 +00:00
|
|
|
struct receive_hook_feed_state {
|
|
|
|
struct command *cmd;
|
2020-08-27 15:45:45 +00:00
|
|
|
struct ref_push_report *report;
|
push options: {pre,post}-receive hook learns about push options
The environment variable GIT_PUSH_OPTION_COUNT is set to the number of
push options sent, and GIT_PUSH_OPTION_{0,1,..} is set to the transmitted
option.
The code is not executed as the push options are set to NULL, nor is the
new capability advertised.
There was some discussion back and forth how to present these push options
to the user as there are some ways to do it:
Keep all options in one environment variable
============================================
+ easiest way to implement in Git
- This would make things hard to parse correctly in the hook.
Put the options in files instead,
filenames are in GIT_PUSH_OPTION_FILES
======================================
+ After a discussion about environment variables and shells, we may not
want to put user data into an environment variable (see [1] for example).
+ We could transmit binaries, i.e. we're not bound to C strings as
we are when using environment variables to the user.
+ Maybe easier to parse than constructing environment variable names
GIT_PUSH_OPTION_{0,1,..} yourself
- cleanup of the temporary files is hard to do reliably
- we have race conditions with multiple clients pushing, hence we'd need
to use mkstemp. That's not too bad, but still.
Use environment variables, but restrict to key/value pairs
==========================================================
(When the user pushes a push option `foo=bar`, we'd
GIT_PUSH_OPTION_foo=bar)
+ very easy to parse for a simple model of push options
- it's not sufficient for more elaborate models, e.g.
it doesn't allow doubles (e.g. cc=reviewer@email)
Present the options in different environment variables
======================================================
(This is implemented)
* harder to parse as a user, but we have a sample hook for that.
- doesn't allow binary files
+ allows the same option twice, i.e. is not restrictive about
options, except for binary files.
+ doesn't clutter a remote directory with (possibly stale)
temporary files
As we first want to focus on getting simple strings to work
reliably, we go with the last option for now. If we want to
do transmission of binaries later, we can just attach a
'side-channel', e.g. "any push option that contains a '\0' is
put into a file instead of the environment variable and we'd
have new GIT_PUSH_OPTION_FILES, GIT_PUSH_OPTION_FILENAME_{0,1,..}
environment variables".
[1] 'Shellshock' https://lwn.net/Articles/614218/
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-14 21:49:45 +00:00
|
|
|
int skip_broken;
|
|
|
|
struct strbuf buf;
|
|
|
|
const struct string_list *push_options;
|
|
|
|
};
|
|
|
|
|
2011-09-08 19:17:09 +00:00
|
|
|
typedef int (*feed_fn)(void *, const char **, size_t *);
|
push options: {pre,post}-receive hook learns about push options
The environment variable GIT_PUSH_OPTION_COUNT is set to the number of
push options sent, and GIT_PUSH_OPTION_{0,1,..} is set to the transmitted
option.
The code is not executed as the push options are set to NULL, nor is the
new capability advertised.
There was some discussion back and forth how to present these push options
to the user as there are some ways to do it:
Keep all options in one environment variable
============================================
+ easiest way to implement in Git
- This would make things hard to parse correctly in the hook.
Put the options in files instead,
filenames are in GIT_PUSH_OPTION_FILES
======================================
+ After a discussion about environment variables and shells, we may not
want to put user data into an environment variable (see [1] for example).
+ We could transmit binaries, i.e. we're not bound to C strings as
we are when using environment variables to the user.
+ Maybe easier to parse than constructing environment variable names
GIT_PUSH_OPTION_{0,1,..} yourself
- cleanup of the temporary files is hard to do reliably
- we have race conditions with multiple clients pushing, hence we'd need
to use mkstemp. That's not too bad, but still.
Use environment variables, but restrict to key/value pairs
==========================================================
(When the user pushes a push option `foo=bar`, we'd
GIT_PUSH_OPTION_foo=bar)
+ very easy to parse for a simple model of push options
- it's not sufficient for more elaborate models, e.g.
it doesn't allow doubles (e.g. cc=reviewer@email)
Present the options in different environment variables
======================================================
(This is implemented)
* harder to parse as a user, but we have a sample hook for that.
- doesn't allow binary files
+ allows the same option twice, i.e. is not restrictive about
options, except for binary files.
+ doesn't clutter a remote directory with (possibly stale)
temporary files
As we first want to focus on getting simple strings to work
reliably, we go with the last option for now. If we want to
do transmission of binaries later, we can just attach a
'side-channel', e.g. "any push option that contains a '\0' is
put into a file instead of the environment variable and we'd
have new GIT_PUSH_OPTION_FILES, GIT_PUSH_OPTION_FILENAME_{0,1,..}
environment variables".
[1] 'Shellshock' https://lwn.net/Articles/614218/
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-14 21:49:45 +00:00
|
|
|
static int run_and_feed_hook(const char *hook_name, feed_fn feed,
|
|
|
|
struct receive_hook_feed_state *feed_state)
|
2005-07-31 19:17:43 +00:00
|
|
|
{
|
2014-08-19 19:09:35 +00:00
|
|
|
struct child_process proc = CHILD_PROCESS_INIT;
|
2010-02-05 20:57:42 +00:00
|
|
|
struct async muxer;
|
2011-09-08 19:17:09 +00:00
|
|
|
int code;
|
2021-11-25 22:52:21 +00:00
|
|
|
const char *hook_path = find_hook(hook_name);
|
2005-07-31 19:17:43 +00:00
|
|
|
|
2021-11-25 22:52:21 +00:00
|
|
|
if (!hook_path)
|
2005-07-31 19:17:43 +00:00
|
|
|
return 0;
|
2007-03-07 21:51:09 +00:00
|
|
|
|
2021-11-25 22:52:21 +00:00
|
|
|
strvec_push(&proc.args, hook_path);
|
2007-03-10 08:28:16 +00:00
|
|
|
proc.in = -1;
|
|
|
|
proc.stdout_to_stderr = 1;
|
2019-02-22 22:25:06 +00:00
|
|
|
proc.trace2_hook_name = hook_name;
|
|
|
|
|
push options: {pre,post}-receive hook learns about push options
The environment variable GIT_PUSH_OPTION_COUNT is set to the number of
push options sent, and GIT_PUSH_OPTION_{0,1,..} is set to the transmitted
option.
The code is not executed as the push options are set to NULL, nor is the
new capability advertised.
There was some discussion back and forth how to present these push options
to the user as there are some ways to do it:
Keep all options in one environment variable
============================================
+ easiest way to implement in Git
- This would make things hard to parse correctly in the hook.
Put the options in files instead,
filenames are in GIT_PUSH_OPTION_FILES
======================================
+ After a discussion about environment variables and shells, we may not
want to put user data into an environment variable (see [1] for example).
+ We could transmit binaries, i.e. we're not bound to C strings as
we are when using environment variables to the user.
+ Maybe easier to parse than constructing environment variable names
GIT_PUSH_OPTION_{0,1,..} yourself
- cleanup of the temporary files is hard to do reliably
- we have race conditions with multiple clients pushing, hence we'd need
to use mkstemp. That's not too bad, but still.
Use environment variables, but restrict to key/value pairs
==========================================================
(When the user pushes a push option `foo=bar`, we'd
GIT_PUSH_OPTION_foo=bar)
+ very easy to parse for a simple model of push options
- it's not sufficient for more elaborate models, e.g.
it doesn't allow doubles (e.g. cc=reviewer@email)
Present the options in different environment variables
======================================================
(This is implemented)
* harder to parse as a user, but we have a sample hook for that.
- doesn't allow binary files
+ allows the same option twice, i.e. is not restrictive about
options, except for binary files.
+ doesn't clutter a remote directory with (possibly stale)
temporary files
As we first want to focus on getting simple strings to work
reliably, we go with the last option for now. If we want to
do transmission of binaries later, we can just attach a
'side-channel', e.g. "any push option that contains a '\0' is
put into a file instead of the environment variable and we'd
have new GIT_PUSH_OPTION_FILES, GIT_PUSH_OPTION_FILENAME_{0,1,..}
environment variables".
[1] 'Shellshock' https://lwn.net/Articles/614218/
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-14 21:49:45 +00:00
|
|
|
if (feed_state->push_options) {
|
2022-03-07 15:27:08 +00:00
|
|
|
size_t i;
|
push options: {pre,post}-receive hook learns about push options
The environment variable GIT_PUSH_OPTION_COUNT is set to the number of
push options sent, and GIT_PUSH_OPTION_{0,1,..} is set to the transmitted
option.
The code is not executed as the push options are set to NULL, nor is the
new capability advertised.
There was some discussion back and forth how to present these push options
to the user as there are some ways to do it:
Keep all options in one environment variable
============================================
+ easiest way to implement in Git
- This would make things hard to parse correctly in the hook.
Put the options in files instead,
filenames are in GIT_PUSH_OPTION_FILES
======================================
+ After a discussion about environment variables and shells, we may not
want to put user data into an environment variable (see [1] for example).
+ We could transmit binaries, i.e. we're not bound to C strings as
we are when using environment variables to the user.
+ Maybe easier to parse than constructing environment variable names
GIT_PUSH_OPTION_{0,1,..} yourself
- cleanup of the temporary files is hard to do reliably
- we have race conditions with multiple clients pushing, hence we'd need
to use mkstemp. That's not too bad, but still.
Use environment variables, but restrict to key/value pairs
==========================================================
(When the user pushes a push option `foo=bar`, we'd
GIT_PUSH_OPTION_foo=bar)
+ very easy to parse for a simple model of push options
- it's not sufficient for more elaborate models, e.g.
it doesn't allow doubles (e.g. cc=reviewer@email)
Present the options in different environment variables
======================================================
(This is implemented)
* harder to parse as a user, but we have a sample hook for that.
- doesn't allow binary files
+ allows the same option twice, i.e. is not restrictive about
options, except for binary files.
+ doesn't clutter a remote directory with (possibly stale)
temporary files
As we first want to focus on getting simple strings to work
reliably, we go with the last option for now. If we want to
do transmission of binaries later, we can just attach a
'side-channel', e.g. "any push option that contains a '\0' is
put into a file instead of the environment variable and we'd
have new GIT_PUSH_OPTION_FILES, GIT_PUSH_OPTION_FILENAME_{0,1,..}
environment variables".
[1] 'Shellshock' https://lwn.net/Articles/614218/
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-14 21:49:45 +00:00
|
|
|
for (i = 0; i < feed_state->push_options->nr; i++)
|
2022-06-02 09:09:50 +00:00
|
|
|
strvec_pushf(&proc.env,
|
2022-03-07 15:27:08 +00:00
|
|
|
"GIT_PUSH_OPTION_%"PRIuMAX"=%s",
|
|
|
|
(uintmax_t)i,
|
strvec: fix indentation in renamed calls
Code which split an argv_array call across multiple lines, like:
argv_array_pushl(&args, "one argument",
"another argument", "and more",
NULL);
was recently mechanically renamed to use strvec, which results in
mis-matched indentation like:
strvec_pushl(&args, "one argument",
"another argument", "and more",
NULL);
Let's fix these up to align the arguments with the opening paren. I did
this manually by sifting through the results of:
git jump grep 'strvec_.*,$'
and liberally applying my editor's auto-format. Most of the changes are
of the form shown above, though I also normalized a few that had
originally used a single-tab indentation (rather than our usual style of
aligning with the open paren). I also rewrapped a couple of obvious
cases (e.g., where previously too-long lines became short enough to fit
on one), but I wasn't aggressive about it. In cases broken to three or
more lines, the grouping of arguments is sometimes meaningful, and it
wasn't worth my time or reviewer time to ponder each case individually.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-28 20:26:31 +00:00
|
|
|
feed_state->push_options->items[i].string);
|
2022-06-02 09:09:50 +00:00
|
|
|
strvec_pushf(&proc.env, "GIT_PUSH_OPTION_COUNT=%"PRIuMAX"",
|
2022-03-07 15:27:08 +00:00
|
|
|
(uintmax_t)feed_state->push_options->nr);
|
push options: {pre,post}-receive hook learns about push options
The environment variable GIT_PUSH_OPTION_COUNT is set to the number of
push options sent, and GIT_PUSH_OPTION_{0,1,..} is set to the transmitted
option.
The code is not executed as the push options are set to NULL, nor is the
new capability advertised.
There was some discussion back and forth how to present these push options
to the user as there are some ways to do it:
Keep all options in one environment variable
============================================
+ easiest way to implement in Git
- This would make things hard to parse correctly in the hook.
Put the options in files instead,
filenames are in GIT_PUSH_OPTION_FILES
======================================
+ After a discussion about environment variables and shells, we may not
want to put user data into an environment variable (see [1] for example).
+ We could transmit binaries, i.e. we're not bound to C strings as
we are when using environment variables to the user.
+ Maybe easier to parse than constructing environment variable names
GIT_PUSH_OPTION_{0,1,..} yourself
- cleanup of the temporary files is hard to do reliably
- we have race conditions with multiple clients pushing, hence we'd need
to use mkstemp. That's not too bad, but still.
Use environment variables, but restrict to key/value pairs
==========================================================
(When the user pushes a push option `foo=bar`, we'd
GIT_PUSH_OPTION_foo=bar)
+ very easy to parse for a simple model of push options
- it's not sufficient for more elaborate models, e.g.
it doesn't allow doubles (e.g. cc=reviewer@email)
Present the options in different environment variables
======================================================
(This is implemented)
* harder to parse as a user, but we have a sample hook for that.
- doesn't allow binary files
+ allows the same option twice, i.e. is not restrictive about
options, except for binary files.
+ doesn't clutter a remote directory with (possibly stale)
temporary files
As we first want to focus on getting simple strings to work
reliably, we go with the last option for now. If we want to
do transmission of binaries later, we can just attach a
'side-channel', e.g. "any push option that contains a '\0' is
put into a file instead of the environment variable and we'd
have new GIT_PUSH_OPTION_FILES, GIT_PUSH_OPTION_FILENAME_{0,1,..}
environment variables".
[1] 'Shellshock' https://lwn.net/Articles/614218/
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-14 21:49:45 +00:00
|
|
|
} else
|
2022-06-02 09:09:50 +00:00
|
|
|
strvec_pushf(&proc.env, "GIT_PUSH_OPTION_COUNT");
|
2007-03-10 08:28:16 +00:00
|
|
|
|
2016-10-03 20:49:14 +00:00
|
|
|
if (tmp_objdir)
|
2022-06-02 09:09:50 +00:00
|
|
|
strvec_pushv(&proc.env, tmp_objdir_env(tmp_objdir));
|
2016-10-03 20:49:14 +00:00
|
|
|
|
2010-02-05 20:57:42 +00:00
|
|
|
if (use_sideband) {
|
|
|
|
memset(&muxer, 0, sizeof(muxer));
|
|
|
|
muxer.proc = copy_to_sideband;
|
|
|
|
muxer.in = -1;
|
|
|
|
code = start_async(&muxer);
|
|
|
|
if (code)
|
|
|
|
return code;
|
|
|
|
proc.err = muxer.in;
|
|
|
|
}
|
|
|
|
|
2014-10-28 20:27:54 +00:00
|
|
|
prepare_push_cert_sha1(&proc);
|
|
|
|
|
2007-03-10 08:28:16 +00:00
|
|
|
code = start_command(&proc);
|
2010-02-05 20:57:42 +00:00
|
|
|
if (code) {
|
|
|
|
if (use_sideband)
|
|
|
|
finish_async(&muxer);
|
2009-07-04 19:26:43 +00:00
|
|
|
return code;
|
2010-02-05 20:57:42 +00:00
|
|
|
}
|
|
|
|
|
receive-pack: allow hooks to ignore its standard input stream
The pre-receive and post-receive hooks were designed to be an
improvement over old style update and post-update hooks, which take
the update information on their command line and are limited by the
command line length limit. The same information is fed from the
standard input to pre/post-receive hooks instead to lift this
limitation. It has been mandatory for these new style hooks to
consume the update information fully from the standard input stream.
Otherwise, they would risk killing the receive-pack process via
SIGPIPE.
If a hook does not want to look at all the information, it is easy
to send its standard input to /dev/null (perhaps a niche use of hook
might need to know only the fact that a push was made, without
having to know what objects have been pushed to update which refs),
and this has already been done by existing hooks that are written
carefully.
However, because there is no good way to consistently fail hooks
that do not consume the input fully (a small push may result in a
short update record that may fit within the pipe buffer, to which
the receive-pack process may manage to write before the hook has a
chance to exit without reading anything, which will not result in a
death-by-SIGPIPE of receive-pack), it can lead to a hard to diagnose
"once in a blue moon" phantom failure.
Lift this "hooks must consume their input fully" mandate. A mandate
that is not enforced strictly is not helping us to catch mistakes in
hooks. If a hook has a good reason to decide the outcome of its
operation without reading the information we feed it, let it do so
as it pleases.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-12 22:48:07 +00:00
|
|
|
sigchain_push(SIGPIPE, SIG_IGN);
|
|
|
|
|
2011-09-08 19:17:09 +00:00
|
|
|
while (1) {
|
|
|
|
const char *buf;
|
|
|
|
size_t n;
|
|
|
|
if (feed(feed_state, &buf, &n))
|
|
|
|
break;
|
avoid "write_in_full(fd, buf, len) != len" pattern
The return value of write_in_full() is either "-1", or the
requested number of bytes[1]. If we make a partial write
before seeing an error, we still return -1, not a partial
value. This goes back to f6aa66cb95 (write_in_full: really
write in full or return error on disk full., 2007-01-11).
So checking anything except "was the return value negative"
is pointless. And there are a couple of reasons not to do
so:
1. It can do a funny signed/unsigned comparison. If your
"len" is signed (e.g., a size_t) then the compiler will
promote the "-1" to its unsigned variant.
This works out for "!= len" (unless you really were
trying to write the maximum size_t bytes), but is a
bug if you check "< len" (an example of which was fixed
recently in config.c).
We should avoid promoting the mental model that you
need to check the length at all, so that new sites are
not tempted to copy us.
2. Checking for a negative value is shorter to type,
especially when the length is an expression.
3. Linus says so. In d34cf19b89 (Clean up write_in_full()
users, 2007-01-11), right after the write_in_full()
semantics were changed, he wrote:
I really wish every "write_in_full()" user would just
check against "<0" now, but this fixes the nasty and
stupid ones.
Appeals to authority aside, this makes it clear that
writing it this way does not have an intentional
benefit. It's a historical curiosity that we never
bothered to clean up (and which was undoubtedly
cargo-culted into new sites).
So let's convert these obviously-correct cases (this
includes write_str_in_full(), which is just a wrapper for
write_in_full()).
[1] A careful reader may notice there is one way that
write_in_full() can return a different value. If we ask
write() to write N bytes and get a return value that is
_larger_ than N, we could return a larger total. But
besides the fact that this would imply a totally broken
version of write(), it would already invoke undefined
behavior. Our internal remaining counter is an unsigned
size_t, which means that subtracting too many byte will
wrap it around to a very large number. So we'll instantly
begin reading off the end of the buffer, trying to write
gigabytes (or petabytes) of data.
Signed-off-by: Jeff King <peff@peff.net>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-13 17:16:03 +00:00
|
|
|
if (write_in_full(proc.in, buf, n) < 0)
|
2011-09-08 19:17:09 +00:00
|
|
|
break;
|
2007-03-07 21:51:09 +00:00
|
|
|
}
|
2008-02-16 17:36:38 +00:00
|
|
|
close(proc.in);
|
2010-02-05 20:57:42 +00:00
|
|
|
if (use_sideband)
|
|
|
|
finish_async(&muxer);
|
receive-pack: allow hooks to ignore its standard input stream
The pre-receive and post-receive hooks were designed to be an
improvement over old style update and post-update hooks, which take
the update information on their command line and are limited by the
command line length limit. The same information is fed from the
standard input to pre/post-receive hooks instead to lift this
limitation. It has been mandatory for these new style hooks to
consume the update information fully from the standard input stream.
Otherwise, they would risk killing the receive-pack process via
SIGPIPE.
If a hook does not want to look at all the information, it is easy
to send its standard input to /dev/null (perhaps a niche use of hook
might need to know only the fact that a push was made, without
having to know what objects have been pushed to update which refs),
and this has already been done by existing hooks that are written
carefully.
However, because there is no good way to consistently fail hooks
that do not consume the input fully (a small push may result in a
short update record that may fit within the pipe buffer, to which
the receive-pack process may manage to write before the hook has a
chance to exit without reading anything, which will not result in a
death-by-SIGPIPE of receive-pack), it can lead to a hard to diagnose
"once in a blue moon" phantom failure.
Lift this "hooks must consume their input fully" mandate. A mandate
that is not enforced strictly is not helping us to catch mistakes in
hooks. If a hook has a good reason to decide the outcome of its
operation without reading the information we feed it, let it do so
as it pleases.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-12 22:48:07 +00:00
|
|
|
|
|
|
|
sigchain_pop(SIGPIPE);
|
|
|
|
|
2009-07-04 19:26:43 +00:00
|
|
|
return finish_command(&proc);
|
2005-07-31 19:17:43 +00:00
|
|
|
}
|
|
|
|
|
2011-09-08 19:17:09 +00:00
|
|
|
static int feed_receive_hook(void *state_, const char **bufp, size_t *sizep)
|
|
|
|
{
|
|
|
|
struct receive_hook_feed_state *state = state_;
|
|
|
|
struct command *cmd = state->cmd;
|
|
|
|
|
2011-10-18 04:37:10 +00:00
|
|
|
while (cmd &&
|
|
|
|
state->skip_broken && (cmd->error_string || cmd->did_not_exist))
|
2011-09-08 19:17:09 +00:00
|
|
|
cmd = cmd->next;
|
|
|
|
if (!cmd)
|
|
|
|
return -1; /* EOF */
|
2020-08-27 15:45:45 +00:00
|
|
|
if (!bufp)
|
|
|
|
return 0; /* OK, can feed something. */
|
2011-09-08 19:17:09 +00:00
|
|
|
strbuf_reset(&state->buf);
|
2020-08-27 15:45:45 +00:00
|
|
|
if (!state->report)
|
|
|
|
state->report = cmd->report;
|
|
|
|
if (state->report) {
|
|
|
|
struct object_id *old_oid;
|
|
|
|
struct object_id *new_oid;
|
|
|
|
const char *ref_name;
|
|
|
|
|
|
|
|
old_oid = state->report->old_oid ? state->report->old_oid : &cmd->old_oid;
|
|
|
|
new_oid = state->report->new_oid ? state->report->new_oid : &cmd->new_oid;
|
|
|
|
ref_name = state->report->ref_name ? state->report->ref_name : cmd->ref_name;
|
|
|
|
strbuf_addf(&state->buf, "%s %s %s\n",
|
|
|
|
oid_to_hex(old_oid), oid_to_hex(new_oid),
|
|
|
|
ref_name);
|
|
|
|
state->report = state->report->next;
|
|
|
|
if (!state->report)
|
|
|
|
state->cmd = cmd->next;
|
|
|
|
} else {
|
|
|
|
strbuf_addf(&state->buf, "%s %s %s\n",
|
|
|
|
oid_to_hex(&cmd->old_oid), oid_to_hex(&cmd->new_oid),
|
|
|
|
cmd->ref_name);
|
|
|
|
state->cmd = cmd->next;
|
|
|
|
}
|
2011-09-08 19:17:09 +00:00
|
|
|
if (bufp) {
|
|
|
|
*bufp = state->buf.buf;
|
|
|
|
*sizep = state->buf.len;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
push options: {pre,post}-receive hook learns about push options
The environment variable GIT_PUSH_OPTION_COUNT is set to the number of
push options sent, and GIT_PUSH_OPTION_{0,1,..} is set to the transmitted
option.
The code is not executed as the push options are set to NULL, nor is the
new capability advertised.
There was some discussion back and forth how to present these push options
to the user as there are some ways to do it:
Keep all options in one environment variable
============================================
+ easiest way to implement in Git
- This would make things hard to parse correctly in the hook.
Put the options in files instead,
filenames are in GIT_PUSH_OPTION_FILES
======================================
+ After a discussion about environment variables and shells, we may not
want to put user data into an environment variable (see [1] for example).
+ We could transmit binaries, i.e. we're not bound to C strings as
we are when using environment variables to the user.
+ Maybe easier to parse than constructing environment variable names
GIT_PUSH_OPTION_{0,1,..} yourself
- cleanup of the temporary files is hard to do reliably
- we have race conditions with multiple clients pushing, hence we'd need
to use mkstemp. That's not too bad, but still.
Use environment variables, but restrict to key/value pairs
==========================================================
(When the user pushes a push option `foo=bar`, we'd
GIT_PUSH_OPTION_foo=bar)
+ very easy to parse for a simple model of push options
- it's not sufficient for more elaborate models, e.g.
it doesn't allow doubles (e.g. cc=reviewer@email)
Present the options in different environment variables
======================================================
(This is implemented)
* harder to parse as a user, but we have a sample hook for that.
- doesn't allow binary files
+ allows the same option twice, i.e. is not restrictive about
options, except for binary files.
+ doesn't clutter a remote directory with (possibly stale)
temporary files
As we first want to focus on getting simple strings to work
reliably, we go with the last option for now. If we want to
do transmission of binaries later, we can just attach a
'side-channel', e.g. "any push option that contains a '\0' is
put into a file instead of the environment variable and we'd
have new GIT_PUSH_OPTION_FILES, GIT_PUSH_OPTION_FILENAME_{0,1,..}
environment variables".
[1] 'Shellshock' https://lwn.net/Articles/614218/
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-14 21:49:45 +00:00
|
|
|
static int run_receive_hook(struct command *commands,
|
|
|
|
const char *hook_name,
|
|
|
|
int skip_broken,
|
|
|
|
const struct string_list *push_options)
|
2011-09-08 19:17:09 +00:00
|
|
|
{
|
|
|
|
struct receive_hook_feed_state state;
|
|
|
|
int status;
|
|
|
|
|
|
|
|
strbuf_init(&state.buf, 0);
|
|
|
|
state.cmd = commands;
|
2011-10-18 04:37:10 +00:00
|
|
|
state.skip_broken = skip_broken;
|
2020-08-27 15:45:45 +00:00
|
|
|
state.report = NULL;
|
2011-09-08 19:17:09 +00:00
|
|
|
if (feed_receive_hook(&state, NULL, NULL))
|
|
|
|
return 0;
|
|
|
|
state.cmd = commands;
|
push options: {pre,post}-receive hook learns about push options
The environment variable GIT_PUSH_OPTION_COUNT is set to the number of
push options sent, and GIT_PUSH_OPTION_{0,1,..} is set to the transmitted
option.
The code is not executed as the push options are set to NULL, nor is the
new capability advertised.
There was some discussion back and forth how to present these push options
to the user as there are some ways to do it:
Keep all options in one environment variable
============================================
+ easiest way to implement in Git
- This would make things hard to parse correctly in the hook.
Put the options in files instead,
filenames are in GIT_PUSH_OPTION_FILES
======================================
+ After a discussion about environment variables and shells, we may not
want to put user data into an environment variable (see [1] for example).
+ We could transmit binaries, i.e. we're not bound to C strings as
we are when using environment variables to the user.
+ Maybe easier to parse than constructing environment variable names
GIT_PUSH_OPTION_{0,1,..} yourself
- cleanup of the temporary files is hard to do reliably
- we have race conditions with multiple clients pushing, hence we'd need
to use mkstemp. That's not too bad, but still.
Use environment variables, but restrict to key/value pairs
==========================================================
(When the user pushes a push option `foo=bar`, we'd
GIT_PUSH_OPTION_foo=bar)
+ very easy to parse for a simple model of push options
- it's not sufficient for more elaborate models, e.g.
it doesn't allow doubles (e.g. cc=reviewer@email)
Present the options in different environment variables
======================================================
(This is implemented)
* harder to parse as a user, but we have a sample hook for that.
- doesn't allow binary files
+ allows the same option twice, i.e. is not restrictive about
options, except for binary files.
+ doesn't clutter a remote directory with (possibly stale)
temporary files
As we first want to focus on getting simple strings to work
reliably, we go with the last option for now. If we want to
do transmission of binaries later, we can just attach a
'side-channel', e.g. "any push option that contains a '\0' is
put into a file instead of the environment variable and we'd
have new GIT_PUSH_OPTION_FILES, GIT_PUSH_OPTION_FILENAME_{0,1,..}
environment variables".
[1] 'Shellshock' https://lwn.net/Articles/614218/
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-14 21:49:45 +00:00
|
|
|
state.push_options = push_options;
|
2011-09-08 19:17:09 +00:00
|
|
|
status = run_and_feed_hook(hook_name, feed_receive_hook, &state);
|
|
|
|
strbuf_release(&state.buf);
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2007-03-10 08:28:13 +00:00
|
|
|
static int run_update_hook(struct command *cmd)
|
|
|
|
{
|
2014-08-19 19:09:35 +00:00
|
|
|
struct child_process proc = CHILD_PROCESS_INIT;
|
2010-02-05 20:57:42 +00:00
|
|
|
int code;
|
2021-11-25 22:52:21 +00:00
|
|
|
const char *hook_path = find_hook("update");
|
2007-03-10 08:28:13 +00:00
|
|
|
|
2021-11-25 22:52:21 +00:00
|
|
|
if (!hook_path)
|
2007-03-10 08:28:13 +00:00
|
|
|
return 0;
|
|
|
|
|
2021-11-25 22:52:21 +00:00
|
|
|
strvec_push(&proc.args, hook_path);
|
|
|
|
strvec_push(&proc.args, cmd->ref_name);
|
|
|
|
strvec_push(&proc.args, oid_to_hex(&cmd->old_oid));
|
|
|
|
strvec_push(&proc.args, oid_to_hex(&cmd->new_oid));
|
2007-03-10 08:28:13 +00:00
|
|
|
|
2010-02-05 20:57:42 +00:00
|
|
|
proc.no_stdin = 1;
|
|
|
|
proc.stdout_to_stderr = 1;
|
|
|
|
proc.err = use_sideband ? -1 : 0;
|
2019-02-22 22:25:06 +00:00
|
|
|
proc.trace2_hook_name = "update";
|
2010-02-05 20:57:42 +00:00
|
|
|
|
|
|
|
code = start_command(&proc);
|
|
|
|
if (code)
|
|
|
|
return code;
|
|
|
|
if (use_sideband)
|
|
|
|
copy_to_sideband(proc.err, -1, NULL);
|
|
|
|
return finish_command(&proc);
|
2007-03-10 08:28:13 +00:00
|
|
|
}
|
|
|
|
|
receive-pack: add new proc-receive hook
Git calls an internal `execute_commands` function to handle commands
sent from client to `git-receive-pack`. Regardless of what references
the user pushes, git creates or updates the corresponding references if
the user has write-permission. A contributor who has no
write-permission, cannot push to the repository directly. So, the
contributor has to write commits to an alternate location, and sends
pull request by emails or by other ways. We call this workflow as a
distributed workflow.
It would be more convenient to work in a centralized workflow like what
Gerrit provided for some cases. For example, a read-only user who
cannot push to a branch directly can run the following `git push`
command to push commits to a pseudo reference (has a prefix "refs/for/",
not "refs/heads/") to create a code review.
git push origin \
HEAD:refs/for/<branch-name>/<session>
The `<branch-name>` in the above example can be as simple as "master",
or a more complicated branch name like "foo/bar". The `<session>` in
the above example command can be the local branch name of the client
side, such as "my/topic".
We cannot implement a centralized workflow elegantly by using
"pre-receive" + "post-receive", because Git will call the internal
function "execute_commands" to create references (even the special
pseudo reference) between these two hooks. Even though we can delete
the temporarily created pseudo reference via the "post-receive" hook,
having a temporary reference is not safe for concurrent pushes.
So, add a filter and a new handler to support this kind of workflow.
The filter will check the prefix of the reference name, and if the
command has a special reference name, the filter will turn a specific
field (`run_proc_receive`) on for the command. Commands with this filed
turned on will be executed by a new handler (a hook named
"proc-receive") instead of the internal `execute_commands` function.
We can use this "proc-receive" command to create pull requests or send
emails for code review.
Suggested by Junio, this "proc-receive" hook reads the commands,
push-options (optional), and send result using a protocol in pkt-line
format. In the following example, the letter "S" stands for
"receive-pack" and letter "H" stands for the hook.
# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive result from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' to execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference. The alternate reference name
# and other status can be given in options
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt
After receiving a command, the hook will execute the command, and may
create/update different reference. For example, a command for a pseudo
reference "refs/for/master/topic" may create/update different reference
such as "refs/pull/123/head". The alternate reference name and other
status are given in option lines.
The list of commands returned from "proc-receive" will replace the
relevant commands that are sent from user to "receive-pack", and
"receive-pack" will continue to run the "execute_commands" function and
other routines. Finally, the result of the execution of these commands
will be reported to end user.
The reporting function from "receive-pack" to "send-pack" will be
extended in latter commit just like what the "proc-receive" hook reports
to "receive-pack".
Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27 15:45:44 +00:00
|
|
|
static struct command *find_command_by_refname(struct command *list,
|
|
|
|
const char *refname)
|
|
|
|
{
|
|
|
|
for (; list; list = list->next)
|
|
|
|
if (!strcmp(list->ref_name, refname))
|
|
|
|
return list;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int read_proc_receive_report(struct packet_reader *reader,
|
|
|
|
struct command *commands,
|
|
|
|
struct strbuf *errmsg)
|
|
|
|
{
|
|
|
|
struct command *cmd;
|
|
|
|
struct command *hint = NULL;
|
|
|
|
struct ref_push_report *report = NULL;
|
|
|
|
int new_report = 0;
|
|
|
|
int code = 0;
|
|
|
|
int once = 0;
|
2020-11-11 11:32:01 +00:00
|
|
|
int response = 0;
|
receive-pack: add new proc-receive hook
Git calls an internal `execute_commands` function to handle commands
sent from client to `git-receive-pack`. Regardless of what references
the user pushes, git creates or updates the corresponding references if
the user has write-permission. A contributor who has no
write-permission, cannot push to the repository directly. So, the
contributor has to write commits to an alternate location, and sends
pull request by emails or by other ways. We call this workflow as a
distributed workflow.
It would be more convenient to work in a centralized workflow like what
Gerrit provided for some cases. For example, a read-only user who
cannot push to a branch directly can run the following `git push`
command to push commits to a pseudo reference (has a prefix "refs/for/",
not "refs/heads/") to create a code review.
git push origin \
HEAD:refs/for/<branch-name>/<session>
The `<branch-name>` in the above example can be as simple as "master",
or a more complicated branch name like "foo/bar". The `<session>` in
the above example command can be the local branch name of the client
side, such as "my/topic".
We cannot implement a centralized workflow elegantly by using
"pre-receive" + "post-receive", because Git will call the internal
function "execute_commands" to create references (even the special
pseudo reference) between these two hooks. Even though we can delete
the temporarily created pseudo reference via the "post-receive" hook,
having a temporary reference is not safe for concurrent pushes.
So, add a filter and a new handler to support this kind of workflow.
The filter will check the prefix of the reference name, and if the
command has a special reference name, the filter will turn a specific
field (`run_proc_receive`) on for the command. Commands with this filed
turned on will be executed by a new handler (a hook named
"proc-receive") instead of the internal `execute_commands` function.
We can use this "proc-receive" command to create pull requests or send
emails for code review.
Suggested by Junio, this "proc-receive" hook reads the commands,
push-options (optional), and send result using a protocol in pkt-line
format. In the following example, the letter "S" stands for
"receive-pack" and letter "H" stands for the hook.
# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive result from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' to execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference. The alternate reference name
# and other status can be given in options
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt
After receiving a command, the hook will execute the command, and may
create/update different reference. For example, a command for a pseudo
reference "refs/for/master/topic" may create/update different reference
such as "refs/pull/123/head". The alternate reference name and other
status are given in option lines.
The list of commands returned from "proc-receive" will replace the
relevant commands that are sent from user to "receive-pack", and
"receive-pack" will continue to run the "execute_commands" function and
other routines. Finally, the result of the execution of these commands
will be reported to end user.
The reporting function from "receive-pack" to "send-pack" will be
extended in latter commit just like what the "proc-receive" hook reports
to "receive-pack".
Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27 15:45:44 +00:00
|
|
|
|
|
|
|
for (;;) {
|
|
|
|
struct object_id old_oid, new_oid;
|
|
|
|
const char *head;
|
|
|
|
const char *refname;
|
|
|
|
char *p;
|
2020-11-11 11:32:01 +00:00
|
|
|
enum packet_read_status status;
|
|
|
|
|
|
|
|
status = packet_reader_read(reader);
|
|
|
|
if (status != PACKET_READ_NORMAL) {
|
|
|
|
/* Check whether proc-receive exited abnormally */
|
|
|
|
if (status == PACKET_READ_EOF && !response) {
|
|
|
|
strbuf_addstr(errmsg, "proc-receive exited abnormally");
|
|
|
|
return -1;
|
|
|
|
}
|
receive-pack: add new proc-receive hook
Git calls an internal `execute_commands` function to handle commands
sent from client to `git-receive-pack`. Regardless of what references
the user pushes, git creates or updates the corresponding references if
the user has write-permission. A contributor who has no
write-permission, cannot push to the repository directly. So, the
contributor has to write commits to an alternate location, and sends
pull request by emails or by other ways. We call this workflow as a
distributed workflow.
It would be more convenient to work in a centralized workflow like what
Gerrit provided for some cases. For example, a read-only user who
cannot push to a branch directly can run the following `git push`
command to push commits to a pseudo reference (has a prefix "refs/for/",
not "refs/heads/") to create a code review.
git push origin \
HEAD:refs/for/<branch-name>/<session>
The `<branch-name>` in the above example can be as simple as "master",
or a more complicated branch name like "foo/bar". The `<session>` in
the above example command can be the local branch name of the client
side, such as "my/topic".
We cannot implement a centralized workflow elegantly by using
"pre-receive" + "post-receive", because Git will call the internal
function "execute_commands" to create references (even the special
pseudo reference) between these two hooks. Even though we can delete
the temporarily created pseudo reference via the "post-receive" hook,
having a temporary reference is not safe for concurrent pushes.
So, add a filter and a new handler to support this kind of workflow.
The filter will check the prefix of the reference name, and if the
command has a special reference name, the filter will turn a specific
field (`run_proc_receive`) on for the command. Commands with this filed
turned on will be executed by a new handler (a hook named
"proc-receive") instead of the internal `execute_commands` function.
We can use this "proc-receive" command to create pull requests or send
emails for code review.
Suggested by Junio, this "proc-receive" hook reads the commands,
push-options (optional), and send result using a protocol in pkt-line
format. In the following example, the letter "S" stands for
"receive-pack" and letter "H" stands for the hook.
# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive result from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' to execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference. The alternate reference name
# and other status can be given in options
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt
After receiving a command, the hook will execute the command, and may
create/update different reference. For example, a command for a pseudo
reference "refs/for/master/topic" may create/update different reference
such as "refs/pull/123/head". The alternate reference name and other
status are given in option lines.
The list of commands returned from "proc-receive" will replace the
relevant commands that are sent from user to "receive-pack", and
"receive-pack" will continue to run the "execute_commands" function and
other routines. Finally, the result of the execution of these commands
will be reported to end user.
The reporting function from "receive-pack" to "send-pack" will be
extended in latter commit just like what the "proc-receive" hook reports
to "receive-pack".
Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27 15:45:44 +00:00
|
|
|
break;
|
2020-11-11 11:32:01 +00:00
|
|
|
}
|
|
|
|
response++;
|
receive-pack: add new proc-receive hook
Git calls an internal `execute_commands` function to handle commands
sent from client to `git-receive-pack`. Regardless of what references
the user pushes, git creates or updates the corresponding references if
the user has write-permission. A contributor who has no
write-permission, cannot push to the repository directly. So, the
contributor has to write commits to an alternate location, and sends
pull request by emails or by other ways. We call this workflow as a
distributed workflow.
It would be more convenient to work in a centralized workflow like what
Gerrit provided for some cases. For example, a read-only user who
cannot push to a branch directly can run the following `git push`
command to push commits to a pseudo reference (has a prefix "refs/for/",
not "refs/heads/") to create a code review.
git push origin \
HEAD:refs/for/<branch-name>/<session>
The `<branch-name>` in the above example can be as simple as "master",
or a more complicated branch name like "foo/bar". The `<session>` in
the above example command can be the local branch name of the client
side, such as "my/topic".
We cannot implement a centralized workflow elegantly by using
"pre-receive" + "post-receive", because Git will call the internal
function "execute_commands" to create references (even the special
pseudo reference) between these two hooks. Even though we can delete
the temporarily created pseudo reference via the "post-receive" hook,
having a temporary reference is not safe for concurrent pushes.
So, add a filter and a new handler to support this kind of workflow.
The filter will check the prefix of the reference name, and if the
command has a special reference name, the filter will turn a specific
field (`run_proc_receive`) on for the command. Commands with this filed
turned on will be executed by a new handler (a hook named
"proc-receive") instead of the internal `execute_commands` function.
We can use this "proc-receive" command to create pull requests or send
emails for code review.
Suggested by Junio, this "proc-receive" hook reads the commands,
push-options (optional), and send result using a protocol in pkt-line
format. In the following example, the letter "S" stands for
"receive-pack" and letter "H" stands for the hook.
# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive result from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' to execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference. The alternate reference name
# and other status can be given in options
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt
After receiving a command, the hook will execute the command, and may
create/update different reference. For example, a command for a pseudo
reference "refs/for/master/topic" may create/update different reference
such as "refs/pull/123/head". The alternate reference name and other
status are given in option lines.
The list of commands returned from "proc-receive" will replace the
relevant commands that are sent from user to "receive-pack", and
"receive-pack" will continue to run the "execute_commands" function and
other routines. Finally, the result of the execution of these commands
will be reported to end user.
The reporting function from "receive-pack" to "send-pack" will be
extended in latter commit just like what the "proc-receive" hook reports
to "receive-pack".
Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27 15:45:44 +00:00
|
|
|
|
|
|
|
head = reader->line;
|
|
|
|
p = strchr(head, ' ');
|
|
|
|
if (!p) {
|
|
|
|
strbuf_addf(errmsg, "proc-receive reported incomplete status line: '%s'\n", head);
|
|
|
|
code = -1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
*p++ = '\0';
|
|
|
|
if (!strcmp(head, "option")) {
|
|
|
|
const char *key, *val;
|
|
|
|
|
|
|
|
if (!hint || !(report || new_report)) {
|
|
|
|
if (!once++)
|
|
|
|
strbuf_addstr(errmsg, "proc-receive reported 'option' without a matching 'ok/ng' directive\n");
|
|
|
|
code = -1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (new_report) {
|
|
|
|
if (!hint->report) {
|
2021-03-13 16:17:22 +00:00
|
|
|
CALLOC_ARRAY(hint->report, 1);
|
receive-pack: add new proc-receive hook
Git calls an internal `execute_commands` function to handle commands
sent from client to `git-receive-pack`. Regardless of what references
the user pushes, git creates or updates the corresponding references if
the user has write-permission. A contributor who has no
write-permission, cannot push to the repository directly. So, the
contributor has to write commits to an alternate location, and sends
pull request by emails or by other ways. We call this workflow as a
distributed workflow.
It would be more convenient to work in a centralized workflow like what
Gerrit provided for some cases. For example, a read-only user who
cannot push to a branch directly can run the following `git push`
command to push commits to a pseudo reference (has a prefix "refs/for/",
not "refs/heads/") to create a code review.
git push origin \
HEAD:refs/for/<branch-name>/<session>
The `<branch-name>` in the above example can be as simple as "master",
or a more complicated branch name like "foo/bar". The `<session>` in
the above example command can be the local branch name of the client
side, such as "my/topic".
We cannot implement a centralized workflow elegantly by using
"pre-receive" + "post-receive", because Git will call the internal
function "execute_commands" to create references (even the special
pseudo reference) between these two hooks. Even though we can delete
the temporarily created pseudo reference via the "post-receive" hook,
having a temporary reference is not safe for concurrent pushes.
So, add a filter and a new handler to support this kind of workflow.
The filter will check the prefix of the reference name, and if the
command has a special reference name, the filter will turn a specific
field (`run_proc_receive`) on for the command. Commands with this filed
turned on will be executed by a new handler (a hook named
"proc-receive") instead of the internal `execute_commands` function.
We can use this "proc-receive" command to create pull requests or send
emails for code review.
Suggested by Junio, this "proc-receive" hook reads the commands,
push-options (optional), and send result using a protocol in pkt-line
format. In the following example, the letter "S" stands for
"receive-pack" and letter "H" stands for the hook.
# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive result from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' to execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference. The alternate reference name
# and other status can be given in options
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt
After receiving a command, the hook will execute the command, and may
create/update different reference. For example, a command for a pseudo
reference "refs/for/master/topic" may create/update different reference
such as "refs/pull/123/head". The alternate reference name and other
status are given in option lines.
The list of commands returned from "proc-receive" will replace the
relevant commands that are sent from user to "receive-pack", and
"receive-pack" will continue to run the "execute_commands" function and
other routines. Finally, the result of the execution of these commands
will be reported to end user.
The reporting function from "receive-pack" to "send-pack" will be
extended in latter commit just like what the "proc-receive" hook reports
to "receive-pack".
Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27 15:45:44 +00:00
|
|
|
report = hint->report;
|
|
|
|
} else {
|
|
|
|
report = hint->report;
|
|
|
|
while (report->next)
|
|
|
|
report = report->next;
|
|
|
|
report->next = xcalloc(1, sizeof(struct ref_push_report));
|
|
|
|
report = report->next;
|
|
|
|
}
|
|
|
|
new_report = 0;
|
|
|
|
}
|
|
|
|
key = p;
|
|
|
|
p = strchr(key, ' ');
|
|
|
|
if (p)
|
|
|
|
*p++ = '\0';
|
|
|
|
val = p;
|
|
|
|
if (!strcmp(key, "refname"))
|
|
|
|
report->ref_name = xstrdup_or_null(val);
|
|
|
|
else if (!strcmp(key, "old-oid") && val &&
|
|
|
|
!parse_oid_hex(val, &old_oid, &val))
|
|
|
|
report->old_oid = oiddup(&old_oid);
|
|
|
|
else if (!strcmp(key, "new-oid") && val &&
|
|
|
|
!parse_oid_hex(val, &new_oid, &val))
|
|
|
|
report->new_oid = oiddup(&new_oid);
|
|
|
|
else if (!strcmp(key, "forced-update"))
|
|
|
|
report->forced_update = 1;
|
|
|
|
else if (!strcmp(key, "fall-through"))
|
|
|
|
/* Fall through, let 'receive-pack' to execute it. */
|
|
|
|
hint->run_proc_receive = 0;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
report = NULL;
|
|
|
|
new_report = 0;
|
|
|
|
refname = p;
|
|
|
|
p = strchr(refname, ' ');
|
|
|
|
if (p)
|
|
|
|
*p++ = '\0';
|
|
|
|
if (strcmp(head, "ok") && strcmp(head, "ng")) {
|
|
|
|
strbuf_addf(errmsg, "proc-receive reported bad status '%s' on ref '%s'\n",
|
|
|
|
head, refname);
|
|
|
|
code = -1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* first try searching at our hint, falling back to all refs */
|
|
|
|
if (hint)
|
|
|
|
hint = find_command_by_refname(hint, refname);
|
|
|
|
if (!hint)
|
|
|
|
hint = find_command_by_refname(commands, refname);
|
|
|
|
if (!hint) {
|
|
|
|
strbuf_addf(errmsg, "proc-receive reported status on unknown ref: %s\n",
|
|
|
|
refname);
|
|
|
|
code = -1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!hint->run_proc_receive) {
|
|
|
|
strbuf_addf(errmsg, "proc-receive reported status on unexpected ref: %s\n",
|
|
|
|
refname);
|
|
|
|
code = -1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
hint->run_proc_receive |= RUN_PROC_RECEIVE_RETURNED;
|
|
|
|
if (!strcmp(head, "ng")) {
|
|
|
|
if (p)
|
|
|
|
hint->error_string = xstrdup(p);
|
|
|
|
else
|
|
|
|
hint->error_string = "failed";
|
|
|
|
code = -1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
new_report = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (cmd = commands; cmd; cmd = cmd->next)
|
|
|
|
if (cmd->run_proc_receive && !cmd->error_string &&
|
|
|
|
!(cmd->run_proc_receive & RUN_PROC_RECEIVE_RETURNED)) {
|
|
|
|
cmd->error_string = "proc-receive failed to report status";
|
|
|
|
code = -1;
|
|
|
|
}
|
|
|
|
return code;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int run_proc_receive_hook(struct command *commands,
|
|
|
|
const struct string_list *push_options)
|
|
|
|
{
|
|
|
|
struct child_process proc = CHILD_PROCESS_INIT;
|
|
|
|
struct async muxer;
|
|
|
|
struct command *cmd;
|
|
|
|
struct packet_reader reader;
|
|
|
|
struct strbuf cap = STRBUF_INIT;
|
|
|
|
struct strbuf errmsg = STRBUF_INIT;
|
|
|
|
int hook_use_push_options = 0;
|
|
|
|
int version = 0;
|
|
|
|
int code;
|
2021-11-25 22:52:21 +00:00
|
|
|
const char *hook_path = find_hook("proc-receive");
|
receive-pack: add new proc-receive hook
Git calls an internal `execute_commands` function to handle commands
sent from client to `git-receive-pack`. Regardless of what references
the user pushes, git creates or updates the corresponding references if
the user has write-permission. A contributor who has no
write-permission, cannot push to the repository directly. So, the
contributor has to write commits to an alternate location, and sends
pull request by emails or by other ways. We call this workflow as a
distributed workflow.
It would be more convenient to work in a centralized workflow like what
Gerrit provided for some cases. For example, a read-only user who
cannot push to a branch directly can run the following `git push`
command to push commits to a pseudo reference (has a prefix "refs/for/",
not "refs/heads/") to create a code review.
git push origin \
HEAD:refs/for/<branch-name>/<session>
The `<branch-name>` in the above example can be as simple as "master",
or a more complicated branch name like "foo/bar". The `<session>` in
the above example command can be the local branch name of the client
side, such as "my/topic".
We cannot implement a centralized workflow elegantly by using
"pre-receive" + "post-receive", because Git will call the internal
function "execute_commands" to create references (even the special
pseudo reference) between these two hooks. Even though we can delete
the temporarily created pseudo reference via the "post-receive" hook,
having a temporary reference is not safe for concurrent pushes.
So, add a filter and a new handler to support this kind of workflow.
The filter will check the prefix of the reference name, and if the
command has a special reference name, the filter will turn a specific
field (`run_proc_receive`) on for the command. Commands with this filed
turned on will be executed by a new handler (a hook named
"proc-receive") instead of the internal `execute_commands` function.
We can use this "proc-receive" command to create pull requests or send
emails for code review.
Suggested by Junio, this "proc-receive" hook reads the commands,
push-options (optional), and send result using a protocol in pkt-line
format. In the following example, the letter "S" stands for
"receive-pack" and letter "H" stands for the hook.
# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive result from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' to execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference. The alternate reference name
# and other status can be given in options
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt
After receiving a command, the hook will execute the command, and may
create/update different reference. For example, a command for a pseudo
reference "refs/for/master/topic" may create/update different reference
such as "refs/pull/123/head". The alternate reference name and other
status are given in option lines.
The list of commands returned from "proc-receive" will replace the
relevant commands that are sent from user to "receive-pack", and
"receive-pack" will continue to run the "execute_commands" function and
other routines. Finally, the result of the execution of these commands
will be reported to end user.
The reporting function from "receive-pack" to "send-pack" will be
extended in latter commit just like what the "proc-receive" hook reports
to "receive-pack".
Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27 15:45:44 +00:00
|
|
|
|
2021-11-25 22:52:21 +00:00
|
|
|
if (!hook_path) {
|
receive-pack: add new proc-receive hook
Git calls an internal `execute_commands` function to handle commands
sent from client to `git-receive-pack`. Regardless of what references
the user pushes, git creates or updates the corresponding references if
the user has write-permission. A contributor who has no
write-permission, cannot push to the repository directly. So, the
contributor has to write commits to an alternate location, and sends
pull request by emails or by other ways. We call this workflow as a
distributed workflow.
It would be more convenient to work in a centralized workflow like what
Gerrit provided for some cases. For example, a read-only user who
cannot push to a branch directly can run the following `git push`
command to push commits to a pseudo reference (has a prefix "refs/for/",
not "refs/heads/") to create a code review.
git push origin \
HEAD:refs/for/<branch-name>/<session>
The `<branch-name>` in the above example can be as simple as "master",
or a more complicated branch name like "foo/bar". The `<session>` in
the above example command can be the local branch name of the client
side, such as "my/topic".
We cannot implement a centralized workflow elegantly by using
"pre-receive" + "post-receive", because Git will call the internal
function "execute_commands" to create references (even the special
pseudo reference) between these two hooks. Even though we can delete
the temporarily created pseudo reference via the "post-receive" hook,
having a temporary reference is not safe for concurrent pushes.
So, add a filter and a new handler to support this kind of workflow.
The filter will check the prefix of the reference name, and if the
command has a special reference name, the filter will turn a specific
field (`run_proc_receive`) on for the command. Commands with this filed
turned on will be executed by a new handler (a hook named
"proc-receive") instead of the internal `execute_commands` function.
We can use this "proc-receive" command to create pull requests or send
emails for code review.
Suggested by Junio, this "proc-receive" hook reads the commands,
push-options (optional), and send result using a protocol in pkt-line
format. In the following example, the letter "S" stands for
"receive-pack" and letter "H" stands for the hook.
# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive result from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' to execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference. The alternate reference name
# and other status can be given in options
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt
After receiving a command, the hook will execute the command, and may
create/update different reference. For example, a command for a pseudo
reference "refs/for/master/topic" may create/update different reference
such as "refs/pull/123/head". The alternate reference name and other
status are given in option lines.
The list of commands returned from "proc-receive" will replace the
relevant commands that are sent from user to "receive-pack", and
"receive-pack" will continue to run the "execute_commands" function and
other routines. Finally, the result of the execution of these commands
will be reported to end user.
The reporting function from "receive-pack" to "send-pack" will be
extended in latter commit just like what the "proc-receive" hook reports
to "receive-pack".
Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27 15:45:44 +00:00
|
|
|
rp_error("cannot find hook 'proc-receive'");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2021-11-25 22:52:21 +00:00
|
|
|
strvec_push(&proc.args, hook_path);
|
receive-pack: add new proc-receive hook
Git calls an internal `execute_commands` function to handle commands
sent from client to `git-receive-pack`. Regardless of what references
the user pushes, git creates or updates the corresponding references if
the user has write-permission. A contributor who has no
write-permission, cannot push to the repository directly. So, the
contributor has to write commits to an alternate location, and sends
pull request by emails or by other ways. We call this workflow as a
distributed workflow.
It would be more convenient to work in a centralized workflow like what
Gerrit provided for some cases. For example, a read-only user who
cannot push to a branch directly can run the following `git push`
command to push commits to a pseudo reference (has a prefix "refs/for/",
not "refs/heads/") to create a code review.
git push origin \
HEAD:refs/for/<branch-name>/<session>
The `<branch-name>` in the above example can be as simple as "master",
or a more complicated branch name like "foo/bar". The `<session>` in
the above example command can be the local branch name of the client
side, such as "my/topic".
We cannot implement a centralized workflow elegantly by using
"pre-receive" + "post-receive", because Git will call the internal
function "execute_commands" to create references (even the special
pseudo reference) between these two hooks. Even though we can delete
the temporarily created pseudo reference via the "post-receive" hook,
having a temporary reference is not safe for concurrent pushes.
So, add a filter and a new handler to support this kind of workflow.
The filter will check the prefix of the reference name, and if the
command has a special reference name, the filter will turn a specific
field (`run_proc_receive`) on for the command. Commands with this filed
turned on will be executed by a new handler (a hook named
"proc-receive") instead of the internal `execute_commands` function.
We can use this "proc-receive" command to create pull requests or send
emails for code review.
Suggested by Junio, this "proc-receive" hook reads the commands,
push-options (optional), and send result using a protocol in pkt-line
format. In the following example, the letter "S" stands for
"receive-pack" and letter "H" stands for the hook.
# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive result from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' to execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference. The alternate reference name
# and other status can be given in options
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt
After receiving a command, the hook will execute the command, and may
create/update different reference. For example, a command for a pseudo
reference "refs/for/master/topic" may create/update different reference
such as "refs/pull/123/head". The alternate reference name and other
status are given in option lines.
The list of commands returned from "proc-receive" will replace the
relevant commands that are sent from user to "receive-pack", and
"receive-pack" will continue to run the "execute_commands" function and
other routines. Finally, the result of the execution of these commands
will be reported to end user.
The reporting function from "receive-pack" to "send-pack" will be
extended in latter commit just like what the "proc-receive" hook reports
to "receive-pack".
Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27 15:45:44 +00:00
|
|
|
proc.in = -1;
|
|
|
|
proc.out = -1;
|
|
|
|
proc.trace2_hook_name = "proc-receive";
|
|
|
|
|
|
|
|
if (use_sideband) {
|
|
|
|
memset(&muxer, 0, sizeof(muxer));
|
|
|
|
muxer.proc = copy_to_sideband;
|
|
|
|
muxer.in = -1;
|
|
|
|
code = start_async(&muxer);
|
|
|
|
if (code)
|
|
|
|
return code;
|
|
|
|
proc.err = muxer.in;
|
|
|
|
} else {
|
|
|
|
proc.err = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
code = start_command(&proc);
|
|
|
|
if (code) {
|
|
|
|
if (use_sideband)
|
|
|
|
finish_async(&muxer);
|
|
|
|
return code;
|
|
|
|
}
|
|
|
|
|
|
|
|
sigchain_push(SIGPIPE, SIG_IGN);
|
|
|
|
|
|
|
|
/* Version negotiaton */
|
|
|
|
packet_reader_init(&reader, proc.out, NULL, 0,
|
|
|
|
PACKET_READ_CHOMP_NEWLINE |
|
|
|
|
PACKET_READ_GENTLE_ON_EOF);
|
|
|
|
if (use_atomic)
|
|
|
|
strbuf_addstr(&cap, " atomic");
|
|
|
|
if (use_push_options)
|
|
|
|
strbuf_addstr(&cap, " push-options");
|
|
|
|
if (cap.len) {
|
2020-11-11 11:32:01 +00:00
|
|
|
code = packet_write_fmt_gently(proc.in, "version=1%c%s\n", '\0', cap.buf + 1);
|
receive-pack: add new proc-receive hook
Git calls an internal `execute_commands` function to handle commands
sent from client to `git-receive-pack`. Regardless of what references
the user pushes, git creates or updates the corresponding references if
the user has write-permission. A contributor who has no
write-permission, cannot push to the repository directly. So, the
contributor has to write commits to an alternate location, and sends
pull request by emails or by other ways. We call this workflow as a
distributed workflow.
It would be more convenient to work in a centralized workflow like what
Gerrit provided for some cases. For example, a read-only user who
cannot push to a branch directly can run the following `git push`
command to push commits to a pseudo reference (has a prefix "refs/for/",
not "refs/heads/") to create a code review.
git push origin \
HEAD:refs/for/<branch-name>/<session>
The `<branch-name>` in the above example can be as simple as "master",
or a more complicated branch name like "foo/bar". The `<session>` in
the above example command can be the local branch name of the client
side, such as "my/topic".
We cannot implement a centralized workflow elegantly by using
"pre-receive" + "post-receive", because Git will call the internal
function "execute_commands" to create references (even the special
pseudo reference) between these two hooks. Even though we can delete
the temporarily created pseudo reference via the "post-receive" hook,
having a temporary reference is not safe for concurrent pushes.
So, add a filter and a new handler to support this kind of workflow.
The filter will check the prefix of the reference name, and if the
command has a special reference name, the filter will turn a specific
field (`run_proc_receive`) on for the command. Commands with this filed
turned on will be executed by a new handler (a hook named
"proc-receive") instead of the internal `execute_commands` function.
We can use this "proc-receive" command to create pull requests or send
emails for code review.
Suggested by Junio, this "proc-receive" hook reads the commands,
push-options (optional), and send result using a protocol in pkt-line
format. In the following example, the letter "S" stands for
"receive-pack" and letter "H" stands for the hook.
# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive result from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' to execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference. The alternate reference name
# and other status can be given in options
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt
After receiving a command, the hook will execute the command, and may
create/update different reference. For example, a command for a pseudo
reference "refs/for/master/topic" may create/update different reference
such as "refs/pull/123/head". The alternate reference name and other
status are given in option lines.
The list of commands returned from "proc-receive" will replace the
relevant commands that are sent from user to "receive-pack", and
"receive-pack" will continue to run the "execute_commands" function and
other routines. Finally, the result of the execution of these commands
will be reported to end user.
The reporting function from "receive-pack" to "send-pack" will be
extended in latter commit just like what the "proc-receive" hook reports
to "receive-pack".
Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27 15:45:44 +00:00
|
|
|
strbuf_release(&cap);
|
|
|
|
} else {
|
2020-11-11 11:32:01 +00:00
|
|
|
code = packet_write_fmt_gently(proc.in, "version=1\n");
|
receive-pack: add new proc-receive hook
Git calls an internal `execute_commands` function to handle commands
sent from client to `git-receive-pack`. Regardless of what references
the user pushes, git creates or updates the corresponding references if
the user has write-permission. A contributor who has no
write-permission, cannot push to the repository directly. So, the
contributor has to write commits to an alternate location, and sends
pull request by emails or by other ways. We call this workflow as a
distributed workflow.
It would be more convenient to work in a centralized workflow like what
Gerrit provided for some cases. For example, a read-only user who
cannot push to a branch directly can run the following `git push`
command to push commits to a pseudo reference (has a prefix "refs/for/",
not "refs/heads/") to create a code review.
git push origin \
HEAD:refs/for/<branch-name>/<session>
The `<branch-name>` in the above example can be as simple as "master",
or a more complicated branch name like "foo/bar". The `<session>` in
the above example command can be the local branch name of the client
side, such as "my/topic".
We cannot implement a centralized workflow elegantly by using
"pre-receive" + "post-receive", because Git will call the internal
function "execute_commands" to create references (even the special
pseudo reference) between these two hooks. Even though we can delete
the temporarily created pseudo reference via the "post-receive" hook,
having a temporary reference is not safe for concurrent pushes.
So, add a filter and a new handler to support this kind of workflow.
The filter will check the prefix of the reference name, and if the
command has a special reference name, the filter will turn a specific
field (`run_proc_receive`) on for the command. Commands with this filed
turned on will be executed by a new handler (a hook named
"proc-receive") instead of the internal `execute_commands` function.
We can use this "proc-receive" command to create pull requests or send
emails for code review.
Suggested by Junio, this "proc-receive" hook reads the commands,
push-options (optional), and send result using a protocol in pkt-line
format. In the following example, the letter "S" stands for
"receive-pack" and letter "H" stands for the hook.
# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive result from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' to execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference. The alternate reference name
# and other status can be given in options
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt
After receiving a command, the hook will execute the command, and may
create/update different reference. For example, a command for a pseudo
reference "refs/for/master/topic" may create/update different reference
such as "refs/pull/123/head". The alternate reference name and other
status are given in option lines.
The list of commands returned from "proc-receive" will replace the
relevant commands that are sent from user to "receive-pack", and
"receive-pack" will continue to run the "execute_commands" function and
other routines. Finally, the result of the execution of these commands
will be reported to end user.
The reporting function from "receive-pack" to "send-pack" will be
extended in latter commit just like what the "proc-receive" hook reports
to "receive-pack".
Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27 15:45:44 +00:00
|
|
|
}
|
2020-11-11 11:32:01 +00:00
|
|
|
if (!code)
|
|
|
|
code = packet_flush_gently(proc.in);
|
|
|
|
|
|
|
|
if (!code)
|
|
|
|
for (;;) {
|
|
|
|
int linelen;
|
|
|
|
enum packet_read_status status;
|
|
|
|
|
|
|
|
status = packet_reader_read(&reader);
|
|
|
|
if (status != PACKET_READ_NORMAL) {
|
|
|
|
/* Check whether proc-receive exited abnormally */
|
|
|
|
if (status == PACKET_READ_EOF)
|
|
|
|
code = -1;
|
|
|
|
break;
|
|
|
|
}
|
receive-pack: add new proc-receive hook
Git calls an internal `execute_commands` function to handle commands
sent from client to `git-receive-pack`. Regardless of what references
the user pushes, git creates or updates the corresponding references if
the user has write-permission. A contributor who has no
write-permission, cannot push to the repository directly. So, the
contributor has to write commits to an alternate location, and sends
pull request by emails or by other ways. We call this workflow as a
distributed workflow.
It would be more convenient to work in a centralized workflow like what
Gerrit provided for some cases. For example, a read-only user who
cannot push to a branch directly can run the following `git push`
command to push commits to a pseudo reference (has a prefix "refs/for/",
not "refs/heads/") to create a code review.
git push origin \
HEAD:refs/for/<branch-name>/<session>
The `<branch-name>` in the above example can be as simple as "master",
or a more complicated branch name like "foo/bar". The `<session>` in
the above example command can be the local branch name of the client
side, such as "my/topic".
We cannot implement a centralized workflow elegantly by using
"pre-receive" + "post-receive", because Git will call the internal
function "execute_commands" to create references (even the special
pseudo reference) between these two hooks. Even though we can delete
the temporarily created pseudo reference via the "post-receive" hook,
having a temporary reference is not safe for concurrent pushes.
So, add a filter and a new handler to support this kind of workflow.
The filter will check the prefix of the reference name, and if the
command has a special reference name, the filter will turn a specific
field (`run_proc_receive`) on for the command. Commands with this filed
turned on will be executed by a new handler (a hook named
"proc-receive") instead of the internal `execute_commands` function.
We can use this "proc-receive" command to create pull requests or send
emails for code review.
Suggested by Junio, this "proc-receive" hook reads the commands,
push-options (optional), and send result using a protocol in pkt-line
format. In the following example, the letter "S" stands for
"receive-pack" and letter "H" stands for the hook.
# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive result from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' to execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference. The alternate reference name
# and other status can be given in options
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt
After receiving a command, the hook will execute the command, and may
create/update different reference. For example, a command for a pseudo
reference "refs/for/master/topic" may create/update different reference
such as "refs/pull/123/head". The alternate reference name and other
status are given in option lines.
The list of commands returned from "proc-receive" will replace the
relevant commands that are sent from user to "receive-pack", and
"receive-pack" will continue to run the "execute_commands" function and
other routines. Finally, the result of the execution of these commands
will be reported to end user.
The reporting function from "receive-pack" to "send-pack" will be
extended in latter commit just like what the "proc-receive" hook reports
to "receive-pack".
Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27 15:45:44 +00:00
|
|
|
|
2020-11-11 11:32:01 +00:00
|
|
|
if (reader.pktlen > 8 && starts_with(reader.line, "version=")) {
|
|
|
|
version = atoi(reader.line + 8);
|
|
|
|
linelen = strlen(reader.line);
|
|
|
|
if (linelen < reader.pktlen) {
|
|
|
|
const char *feature_list = reader.line + linelen + 1;
|
|
|
|
if (parse_feature_request(feature_list, "push-options"))
|
|
|
|
hook_use_push_options = 1;
|
|
|
|
}
|
receive-pack: add new proc-receive hook
Git calls an internal `execute_commands` function to handle commands
sent from client to `git-receive-pack`. Regardless of what references
the user pushes, git creates or updates the corresponding references if
the user has write-permission. A contributor who has no
write-permission, cannot push to the repository directly. So, the
contributor has to write commits to an alternate location, and sends
pull request by emails or by other ways. We call this workflow as a
distributed workflow.
It would be more convenient to work in a centralized workflow like what
Gerrit provided for some cases. For example, a read-only user who
cannot push to a branch directly can run the following `git push`
command to push commits to a pseudo reference (has a prefix "refs/for/",
not "refs/heads/") to create a code review.
git push origin \
HEAD:refs/for/<branch-name>/<session>
The `<branch-name>` in the above example can be as simple as "master",
or a more complicated branch name like "foo/bar". The `<session>` in
the above example command can be the local branch name of the client
side, such as "my/topic".
We cannot implement a centralized workflow elegantly by using
"pre-receive" + "post-receive", because Git will call the internal
function "execute_commands" to create references (even the special
pseudo reference) between these two hooks. Even though we can delete
the temporarily created pseudo reference via the "post-receive" hook,
having a temporary reference is not safe for concurrent pushes.
So, add a filter and a new handler to support this kind of workflow.
The filter will check the prefix of the reference name, and if the
command has a special reference name, the filter will turn a specific
field (`run_proc_receive`) on for the command. Commands with this filed
turned on will be executed by a new handler (a hook named
"proc-receive") instead of the internal `execute_commands` function.
We can use this "proc-receive" command to create pull requests or send
emails for code review.
Suggested by Junio, this "proc-receive" hook reads the commands,
push-options (optional), and send result using a protocol in pkt-line
format. In the following example, the letter "S" stands for
"receive-pack" and letter "H" stands for the hook.
# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive result from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' to execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference. The alternate reference name
# and other status can be given in options
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt
After receiving a command, the hook will execute the command, and may
create/update different reference. For example, a command for a pseudo
reference "refs/for/master/topic" may create/update different reference
such as "refs/pull/123/head". The alternate reference name and other
status are given in option lines.
The list of commands returned from "proc-receive" will replace the
relevant commands that are sent from user to "receive-pack", and
"receive-pack" will continue to run the "execute_commands" function and
other routines. Finally, the result of the execution of these commands
will be reported to end user.
The reporting function from "receive-pack" to "send-pack" will be
extended in latter commit just like what the "proc-receive" hook reports
to "receive-pack".
Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27 15:45:44 +00:00
|
|
|
}
|
|
|
|
}
|
2020-11-11 11:32:01 +00:00
|
|
|
|
|
|
|
if (code) {
|
|
|
|
strbuf_addstr(&errmsg, "fail to negotiate version with proc-receive hook");
|
|
|
|
goto cleanup;
|
receive-pack: add new proc-receive hook
Git calls an internal `execute_commands` function to handle commands
sent from client to `git-receive-pack`. Regardless of what references
the user pushes, git creates or updates the corresponding references if
the user has write-permission. A contributor who has no
write-permission, cannot push to the repository directly. So, the
contributor has to write commits to an alternate location, and sends
pull request by emails or by other ways. We call this workflow as a
distributed workflow.
It would be more convenient to work in a centralized workflow like what
Gerrit provided for some cases. For example, a read-only user who
cannot push to a branch directly can run the following `git push`
command to push commits to a pseudo reference (has a prefix "refs/for/",
not "refs/heads/") to create a code review.
git push origin \
HEAD:refs/for/<branch-name>/<session>
The `<branch-name>` in the above example can be as simple as "master",
or a more complicated branch name like "foo/bar". The `<session>` in
the above example command can be the local branch name of the client
side, such as "my/topic".
We cannot implement a centralized workflow elegantly by using
"pre-receive" + "post-receive", because Git will call the internal
function "execute_commands" to create references (even the special
pseudo reference) between these two hooks. Even though we can delete
the temporarily created pseudo reference via the "post-receive" hook,
having a temporary reference is not safe for concurrent pushes.
So, add a filter and a new handler to support this kind of workflow.
The filter will check the prefix of the reference name, and if the
command has a special reference name, the filter will turn a specific
field (`run_proc_receive`) on for the command. Commands with this filed
turned on will be executed by a new handler (a hook named
"proc-receive") instead of the internal `execute_commands` function.
We can use this "proc-receive" command to create pull requests or send
emails for code review.
Suggested by Junio, this "proc-receive" hook reads the commands,
push-options (optional), and send result using a protocol in pkt-line
format. In the following example, the letter "S" stands for
"receive-pack" and letter "H" stands for the hook.
# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive result from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' to execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference. The alternate reference name
# and other status can be given in options
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt
After receiving a command, the hook will execute the command, and may
create/update different reference. For example, a command for a pseudo
reference "refs/for/master/topic" may create/update different reference
such as "refs/pull/123/head". The alternate reference name and other
status are given in option lines.
The list of commands returned from "proc-receive" will replace the
relevant commands that are sent from user to "receive-pack", and
"receive-pack" will continue to run the "execute_commands" function and
other routines. Finally, the result of the execution of these commands
will be reported to end user.
The reporting function from "receive-pack" to "send-pack" will be
extended in latter commit just like what the "proc-receive" hook reports
to "receive-pack".
Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27 15:45:44 +00:00
|
|
|
}
|
|
|
|
|
2020-11-11 11:32:02 +00:00
|
|
|
switch (version) {
|
|
|
|
case 0:
|
|
|
|
/* fallthrough */
|
|
|
|
case 1:
|
|
|
|
break;
|
|
|
|
default:
|
receive-pack: add new proc-receive hook
Git calls an internal `execute_commands` function to handle commands
sent from client to `git-receive-pack`. Regardless of what references
the user pushes, git creates or updates the corresponding references if
the user has write-permission. A contributor who has no
write-permission, cannot push to the repository directly. So, the
contributor has to write commits to an alternate location, and sends
pull request by emails or by other ways. We call this workflow as a
distributed workflow.
It would be more convenient to work in a centralized workflow like what
Gerrit provided for some cases. For example, a read-only user who
cannot push to a branch directly can run the following `git push`
command to push commits to a pseudo reference (has a prefix "refs/for/",
not "refs/heads/") to create a code review.
git push origin \
HEAD:refs/for/<branch-name>/<session>
The `<branch-name>` in the above example can be as simple as "master",
or a more complicated branch name like "foo/bar". The `<session>` in
the above example command can be the local branch name of the client
side, such as "my/topic".
We cannot implement a centralized workflow elegantly by using
"pre-receive" + "post-receive", because Git will call the internal
function "execute_commands" to create references (even the special
pseudo reference) between these two hooks. Even though we can delete
the temporarily created pseudo reference via the "post-receive" hook,
having a temporary reference is not safe for concurrent pushes.
So, add a filter and a new handler to support this kind of workflow.
The filter will check the prefix of the reference name, and if the
command has a special reference name, the filter will turn a specific
field (`run_proc_receive`) on for the command. Commands with this filed
turned on will be executed by a new handler (a hook named
"proc-receive") instead of the internal `execute_commands` function.
We can use this "proc-receive" command to create pull requests or send
emails for code review.
Suggested by Junio, this "proc-receive" hook reads the commands,
push-options (optional), and send result using a protocol in pkt-line
format. In the following example, the letter "S" stands for
"receive-pack" and letter "H" stands for the hook.
# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive result from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' to execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference. The alternate reference name
# and other status can be given in options
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt
After receiving a command, the hook will execute the command, and may
create/update different reference. For example, a command for a pseudo
reference "refs/for/master/topic" may create/update different reference
such as "refs/pull/123/head". The alternate reference name and other
status are given in option lines.
The list of commands returned from "proc-receive" will replace the
relevant commands that are sent from user to "receive-pack", and
"receive-pack" will continue to run the "execute_commands" function and
other routines. Finally, the result of the execution of these commands
will be reported to end user.
The reporting function from "receive-pack" to "send-pack" will be
extended in latter commit just like what the "proc-receive" hook reports
to "receive-pack".
Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27 15:45:44 +00:00
|
|
|
strbuf_addf(&errmsg, "proc-receive version '%d' is not supported",
|
|
|
|
version);
|
|
|
|
code = -1;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Send commands */
|
|
|
|
for (cmd = commands; cmd; cmd = cmd->next) {
|
|
|
|
if (!cmd->run_proc_receive || cmd->skip_update || cmd->error_string)
|
|
|
|
continue;
|
2020-11-11 11:32:01 +00:00
|
|
|
code = packet_write_fmt_gently(proc.in, "%s %s %s",
|
|
|
|
oid_to_hex(&cmd->old_oid),
|
|
|
|
oid_to_hex(&cmd->new_oid),
|
|
|
|
cmd->ref_name);
|
|
|
|
if (code)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (!code)
|
|
|
|
code = packet_flush_gently(proc.in);
|
|
|
|
if (code) {
|
|
|
|
strbuf_addstr(&errmsg, "fail to write commands to proc-receive hook");
|
|
|
|
goto cleanup;
|
receive-pack: add new proc-receive hook
Git calls an internal `execute_commands` function to handle commands
sent from client to `git-receive-pack`. Regardless of what references
the user pushes, git creates or updates the corresponding references if
the user has write-permission. A contributor who has no
write-permission, cannot push to the repository directly. So, the
contributor has to write commits to an alternate location, and sends
pull request by emails or by other ways. We call this workflow as a
distributed workflow.
It would be more convenient to work in a centralized workflow like what
Gerrit provided for some cases. For example, a read-only user who
cannot push to a branch directly can run the following `git push`
command to push commits to a pseudo reference (has a prefix "refs/for/",
not "refs/heads/") to create a code review.
git push origin \
HEAD:refs/for/<branch-name>/<session>
The `<branch-name>` in the above example can be as simple as "master",
or a more complicated branch name like "foo/bar". The `<session>` in
the above example command can be the local branch name of the client
side, such as "my/topic".
We cannot implement a centralized workflow elegantly by using
"pre-receive" + "post-receive", because Git will call the internal
function "execute_commands" to create references (even the special
pseudo reference) between these two hooks. Even though we can delete
the temporarily created pseudo reference via the "post-receive" hook,
having a temporary reference is not safe for concurrent pushes.
So, add a filter and a new handler to support this kind of workflow.
The filter will check the prefix of the reference name, and if the
command has a special reference name, the filter will turn a specific
field (`run_proc_receive`) on for the command. Commands with this filed
turned on will be executed by a new handler (a hook named
"proc-receive") instead of the internal `execute_commands` function.
We can use this "proc-receive" command to create pull requests or send
emails for code review.
Suggested by Junio, this "proc-receive" hook reads the commands,
push-options (optional), and send result using a protocol in pkt-line
format. In the following example, the letter "S" stands for
"receive-pack" and letter "H" stands for the hook.
# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive result from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' to execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference. The alternate reference name
# and other status can be given in options
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt
After receiving a command, the hook will execute the command, and may
create/update different reference. For example, a command for a pseudo
reference "refs/for/master/topic" may create/update different reference
such as "refs/pull/123/head". The alternate reference name and other
status are given in option lines.
The list of commands returned from "proc-receive" will replace the
relevant commands that are sent from user to "receive-pack", and
"receive-pack" will continue to run the "execute_commands" function and
other routines. Finally, the result of the execution of these commands
will be reported to end user.
The reporting function from "receive-pack" to "send-pack" will be
extended in latter commit just like what the "proc-receive" hook reports
to "receive-pack".
Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27 15:45:44 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Send push options */
|
|
|
|
if (hook_use_push_options) {
|
|
|
|
struct string_list_item *item;
|
|
|
|
|
2020-11-11 11:32:01 +00:00
|
|
|
for_each_string_list_item(item, push_options) {
|
|
|
|
code = packet_write_fmt_gently(proc.in, "%s", item->string);
|
|
|
|
if (code)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (!code)
|
|
|
|
code = packet_flush_gently(proc.in);
|
|
|
|
if (code) {
|
|
|
|
strbuf_addstr(&errmsg,
|
|
|
|
"fail to write push-options to proc-receive hook");
|
|
|
|
goto cleanup;
|
|
|
|
}
|
receive-pack: add new proc-receive hook
Git calls an internal `execute_commands` function to handle commands
sent from client to `git-receive-pack`. Regardless of what references
the user pushes, git creates or updates the corresponding references if
the user has write-permission. A contributor who has no
write-permission, cannot push to the repository directly. So, the
contributor has to write commits to an alternate location, and sends
pull request by emails or by other ways. We call this workflow as a
distributed workflow.
It would be more convenient to work in a centralized workflow like what
Gerrit provided for some cases. For example, a read-only user who
cannot push to a branch directly can run the following `git push`
command to push commits to a pseudo reference (has a prefix "refs/for/",
not "refs/heads/") to create a code review.
git push origin \
HEAD:refs/for/<branch-name>/<session>
The `<branch-name>` in the above example can be as simple as "master",
or a more complicated branch name like "foo/bar". The `<session>` in
the above example command can be the local branch name of the client
side, such as "my/topic".
We cannot implement a centralized workflow elegantly by using
"pre-receive" + "post-receive", because Git will call the internal
function "execute_commands" to create references (even the special
pseudo reference) between these two hooks. Even though we can delete
the temporarily created pseudo reference via the "post-receive" hook,
having a temporary reference is not safe for concurrent pushes.
So, add a filter and a new handler to support this kind of workflow.
The filter will check the prefix of the reference name, and if the
command has a special reference name, the filter will turn a specific
field (`run_proc_receive`) on for the command. Commands with this filed
turned on will be executed by a new handler (a hook named
"proc-receive") instead of the internal `execute_commands` function.
We can use this "proc-receive" command to create pull requests or send
emails for code review.
Suggested by Junio, this "proc-receive" hook reads the commands,
push-options (optional), and send result using a protocol in pkt-line
format. In the following example, the letter "S" stands for
"receive-pack" and letter "H" stands for the hook.
# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive result from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' to execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference. The alternate reference name
# and other status can be given in options
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt
After receiving a command, the hook will execute the command, and may
create/update different reference. For example, a command for a pseudo
reference "refs/for/master/topic" may create/update different reference
such as "refs/pull/123/head". The alternate reference name and other
status are given in option lines.
The list of commands returned from "proc-receive" will replace the
relevant commands that are sent from user to "receive-pack", and
"receive-pack" will continue to run the "execute_commands" function and
other routines. Finally, the result of the execution of these commands
will be reported to end user.
The reporting function from "receive-pack" to "send-pack" will be
extended in latter commit just like what the "proc-receive" hook reports
to "receive-pack".
Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27 15:45:44 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Read result from proc-receive */
|
|
|
|
code = read_proc_receive_report(&reader, commands, &errmsg);
|
|
|
|
|
|
|
|
cleanup:
|
|
|
|
close(proc.in);
|
|
|
|
close(proc.out);
|
|
|
|
if (use_sideband)
|
|
|
|
finish_async(&muxer);
|
|
|
|
if (finish_command(&proc))
|
|
|
|
code = -1;
|
|
|
|
if (errmsg.len >0) {
|
|
|
|
char *p = errmsg.buf;
|
|
|
|
|
|
|
|
p += errmsg.len - 1;
|
|
|
|
if (*p == '\n')
|
|
|
|
*p = '\0';
|
|
|
|
rp_error("%s", errmsg.buf);
|
|
|
|
strbuf_release(&errmsg);
|
|
|
|
}
|
|
|
|
sigchain_pop(SIGPIPE);
|
|
|
|
|
|
|
|
return code;
|
|
|
|
}
|
|
|
|
|
2016-09-15 14:59:05 +00:00
|
|
|
static char *refuse_unconfigured_deny_msg =
|
|
|
|
N_("By default, updating the current branch in a non-bare repository\n"
|
|
|
|
"is denied, because it will make the index and work tree inconsistent\n"
|
|
|
|
"with what you pushed, and will require 'git reset --hard' to match\n"
|
|
|
|
"the work tree to HEAD.\n"
|
|
|
|
"\n"
|
2016-12-04 22:04:40 +00:00
|
|
|
"You can set the 'receive.denyCurrentBranch' configuration variable\n"
|
|
|
|
"to 'ignore' or 'warn' in the remote repository to allow pushing into\n"
|
2016-09-15 14:59:05 +00:00
|
|
|
"its current branch; however, this is not recommended unless you\n"
|
|
|
|
"arranged to update its work tree to match what you pushed in some\n"
|
|
|
|
"other way.\n"
|
|
|
|
"\n"
|
|
|
|
"To squelch this message and still keep the default behaviour, set\n"
|
|
|
|
"'receive.denyCurrentBranch' configuration variable to 'refuse'.");
|
2009-02-01 01:34:05 +00:00
|
|
|
|
2009-02-11 10:28:03 +00:00
|
|
|
static void refuse_unconfigured_deny(void)
|
2009-02-01 01:34:05 +00:00
|
|
|
{
|
2016-09-15 14:59:05 +00:00
|
|
|
rp_error("%s", _(refuse_unconfigured_deny_msg));
|
2009-02-01 01:34:05 +00:00
|
|
|
}
|
|
|
|
|
2016-09-15 14:59:05 +00:00
|
|
|
static char *refuse_unconfigured_deny_delete_current_msg =
|
|
|
|
N_("By default, deleting the current branch is denied, because the next\n"
|
|
|
|
"'git clone' won't result in any file checked out, causing confusion.\n"
|
|
|
|
"\n"
|
|
|
|
"You can set 'receive.denyDeleteCurrent' configuration variable to\n"
|
|
|
|
"'warn' or 'ignore' in the remote repository to allow deleting the\n"
|
|
|
|
"current branch, with or without a warning message.\n"
|
|
|
|
"\n"
|
|
|
|
"To squelch this message, you can set it to 'refuse'.");
|
2009-02-09 06:31:21 +00:00
|
|
|
|
2009-02-09 08:19:46 +00:00
|
|
|
static void refuse_unconfigured_deny_delete_current(void)
|
2009-02-09 06:31:21 +00:00
|
|
|
{
|
2016-09-15 14:59:05 +00:00
|
|
|
rp_error("%s", _(refuse_unconfigured_deny_delete_current_msg));
|
2009-02-09 06:31:21 +00:00
|
|
|
}
|
|
|
|
|
2021-09-01 13:09:50 +00:00
|
|
|
static const struct object_id *command_singleton_iterator(void *cb_data);
|
2013-12-05 13:02:47 +00:00
|
|
|
static int update_shallow_ref(struct command *cmd, struct shallow_info *si)
|
|
|
|
{
|
2020-04-30 19:48:57 +00:00
|
|
|
struct shallow_lock shallow_lock = SHALLOW_LOCK_INIT;
|
2017-03-31 01:40:00 +00:00
|
|
|
struct oid_array extra = OID_ARRAY_INIT;
|
check_everything_connected: use a struct with named options
The number of variants of check_everything_connected has
grown over the years, so that the "real" function takes
several possibly-zero, possibly-NULL arguments. We hid the
complexity behind some wrapper functions, but this doesn't
scale well when we want to add new options.
If we add more wrapper variants to handle the new options,
then we can get a combinatorial explosion when those options
might be used together (right now nobody wants to use both
"shallow" and "transport" together, so we get by with just a
few wrappers).
If instead we add new parameters to each function, each of
which can have a default value, then callers who want the
defaults end up with confusing invocations like:
check_everything_connected(fn, 0, data, -1, 0, NULL);
where it is unclear which parameter is which (and every
caller needs updated when we add new options).
Instead, let's add a struct to hold all of the optional
parameters. This is a little more verbose for the callers
(who have to declare the struct and fill it in), but it
makes their code much easier to follow, because every option
is named as it is set (and unused options do not have to be
mentioned at all).
Note that we could also stick the iteration function and its
callback data into the option struct, too. But since those
are required for each call, by avoiding doing so, we can let
very simple callers just pass "NULL" for the options and not
worry about the struct at all.
While we're touching each site, let's also rename the
function to check_connected(). The existing name was quite
long, and not all of the wrappers even used the full name.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-15 10:30:40 +00:00
|
|
|
struct check_connected_options opt = CHECK_CONNECTED_INIT;
|
2013-12-05 13:02:47 +00:00
|
|
|
uint32_t mask = 1 << (cmd->index % 32);
|
|
|
|
int i;
|
|
|
|
|
2014-07-12 00:00:06 +00:00
|
|
|
trace_printf_key(&trace_shallow,
|
2013-12-05 13:02:47 +00:00
|
|
|
"shallow: update_shallow_ref %s\n", cmd->ref_name);
|
|
|
|
for (i = 0; i < si->shallow->nr; i++)
|
|
|
|
if (si->used_shallow[i] &&
|
|
|
|
(si->used_shallow[i][cmd->index / 32] & mask) &&
|
|
|
|
!delayed_reachability_test(si, i))
|
2017-03-31 01:40:00 +00:00
|
|
|
oid_array_append(&extra, &si->shallow->oid[i]);
|
2013-12-05 13:02:47 +00:00
|
|
|
|
2016-10-03 20:49:14 +00:00
|
|
|
opt.env = tmp_objdir_env(tmp_objdir);
|
check_everything_connected: use a struct with named options
The number of variants of check_everything_connected has
grown over the years, so that the "real" function takes
several possibly-zero, possibly-NULL arguments. We hid the
complexity behind some wrapper functions, but this doesn't
scale well when we want to add new options.
If we add more wrapper variants to handle the new options,
then we can get a combinatorial explosion when those options
might be used together (right now nobody wants to use both
"shallow" and "transport" together, so we get by with just a
few wrappers).
If instead we add new parameters to each function, each of
which can have a default value, then callers who want the
defaults end up with confusing invocations like:
check_everything_connected(fn, 0, data, -1, 0, NULL);
where it is unclear which parameter is which (and every
caller needs updated when we add new options).
Instead, let's add a struct to hold all of the optional
parameters. This is a little more verbose for the callers
(who have to declare the struct and fill it in), but it
makes their code much easier to follow, because every option
is named as it is set (and unused options do not have to be
mentioned at all).
Note that we could also stick the iteration function and its
callback data into the option struct, too. But since those
are required for each call, by avoiding doing so, we can let
very simple callers just pass "NULL" for the options and not
worry about the struct at all.
While we're touching each site, let's also rename the
function to check_connected(). The existing name was quite
long, and not all of the wrappers even used the full name.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-15 10:30:40 +00:00
|
|
|
setup_alternate_shallow(&shallow_lock, &opt.shallow_file, &extra);
|
|
|
|
if (check_connected(command_singleton_iterator, cmd, &opt)) {
|
shallow.c: use '{commit,rollback}_shallow_file'
In bd0b42aed3 (fetch-pack: do not take shallow lock unnecessarily,
2019-01-10), the author noted that 'is_repository_shallow' produces
visible side-effect(s) by setting 'is_shallow' and 'shallow_stat'.
This is a problem for e.g., fetching with '--update-shallow' in a
shallow repository with 'fetch.writeCommitGraph' enabled, since the
update to '.git/shallow' will cause Git to think that the repository
isn't shallow when it is, thereby circumventing the commit-graph
compatibility check.
This causes problems in shallow repositories with at least shallow refs
that have at least one ancestor (since the client won't have those
objects, and therefore can't take the reachability closure over commits
when writing a commit-graph).
Address this by introducing thin wrappers over 'commit_lock_file' and
'rollback_lock_file' for use specifically when the lock is held over
'.git/shallow'. These wrappers (appropriately called
'commit_shallow_file' and 'rollback_shallow_file') call into their
respective functions in 'lockfile.h', but additionally reset validity
checks used by the shallow machinery.
Replace each instance of 'commit_lock_file' and 'rollback_lock_file'
with 'commit_shallow_file' and 'rollback_shallow_file' when the lock
being held is over the '.git/shallow' file.
As a result, 'prune_shallow' can now only be called once (since
'check_shallow_file_for_update' will die after calling
'reset_repository_shallow'). But, this is OK since we only call
'prune_shallow' at most once per process.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Reviewed-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-23 00:25:45 +00:00
|
|
|
rollback_shallow_file(the_repository, &shallow_lock);
|
2017-03-31 01:40:00 +00:00
|
|
|
oid_array_clear(&extra);
|
2013-12-05 13:02:47 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
shallow.c: use '{commit,rollback}_shallow_file'
In bd0b42aed3 (fetch-pack: do not take shallow lock unnecessarily,
2019-01-10), the author noted that 'is_repository_shallow' produces
visible side-effect(s) by setting 'is_shallow' and 'shallow_stat'.
This is a problem for e.g., fetching with '--update-shallow' in a
shallow repository with 'fetch.writeCommitGraph' enabled, since the
update to '.git/shallow' will cause Git to think that the repository
isn't shallow when it is, thereby circumventing the commit-graph
compatibility check.
This causes problems in shallow repositories with at least shallow refs
that have at least one ancestor (since the client won't have those
objects, and therefore can't take the reachability closure over commits
when writing a commit-graph).
Address this by introducing thin wrappers over 'commit_lock_file' and
'rollback_lock_file' for use specifically when the lock is held over
'.git/shallow'. These wrappers (appropriately called
'commit_shallow_file' and 'rollback_shallow_file') call into their
respective functions in 'lockfile.h', but additionally reset validity
checks used by the shallow machinery.
Replace each instance of 'commit_lock_file' and 'rollback_lock_file'
with 'commit_shallow_file' and 'rollback_shallow_file' when the lock
being held is over the '.git/shallow' file.
As a result, 'prune_shallow' can now only be called once (since
'check_shallow_file_for_update' will die after calling
'reset_repository_shallow'). But, this is OK since we only call
'prune_shallow' at most once per process.
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Reviewed-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-23 00:25:45 +00:00
|
|
|
commit_shallow_file(the_repository, &shallow_lock);
|
2013-12-05 13:02:47 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Make sure setup_alternate_shallow() for the next ref does
|
|
|
|
* not lose these new roots..
|
|
|
|
*/
|
|
|
|
for (i = 0; i < extra.nr; i++)
|
2018-05-17 22:51:44 +00:00
|
|
|
register_shallow(the_repository, &extra.oid[i]);
|
2013-12-05 13:02:47 +00:00
|
|
|
|
|
|
|
si->shallow_ref[cmd->index] = 0;
|
2017-03-31 01:40:00 +00:00
|
|
|
oid_array_clear(&extra);
|
2013-12-05 13:02:47 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-04-01 06:15:45 +00:00
|
|
|
/*
|
|
|
|
* NEEDSWORK: we should consolidate various implementions of "are we
|
|
|
|
* on an unborn branch?" test into one, and make the unified one more
|
|
|
|
* robust. !get_sha1() based check used here and elsewhere would not
|
|
|
|
* allow us to tell an unborn branch from corrupt ref, for example.
|
|
|
|
* For the purpose of fixing "deploy-to-update does not work when
|
|
|
|
* pushing into an empty repository" issue, this should suffice for
|
|
|
|
* now.
|
|
|
|
*/
|
|
|
|
static int head_has_history(void)
|
|
|
|
{
|
2017-07-13 23:49:27 +00:00
|
|
|
struct object_id oid;
|
2015-04-01 06:15:45 +00:00
|
|
|
|
2023-03-28 13:58:46 +00:00
|
|
|
return !repo_get_oid(the_repository, "HEAD", &oid);
|
2015-04-01 06:15:45 +00:00
|
|
|
}
|
|
|
|
|
2014-12-01 21:57:28 +00:00
|
|
|
static const char *push_to_deploy(unsigned char *sha1,
|
2020-07-28 20:24:27 +00:00
|
|
|
struct strvec *env,
|
2014-12-01 21:57:28 +00:00
|
|
|
const char *work_tree)
|
2014-11-26 22:44:16 +00:00
|
|
|
{
|
|
|
|
struct child_process child = CHILD_PROCESS_INIT;
|
|
|
|
|
2021-11-25 22:52:20 +00:00
|
|
|
strvec_pushl(&child.args, "update-index", "-q", "--ignore-submodules",
|
|
|
|
"--refresh", NULL);
|
2022-06-02 09:09:50 +00:00
|
|
|
strvec_pushv(&child.env, env->v);
|
2014-11-26 22:44:16 +00:00
|
|
|
child.dir = work_tree;
|
|
|
|
child.no_stdin = 1;
|
|
|
|
child.stdout_to_stderr = 1;
|
|
|
|
child.git_cmd = 1;
|
2014-12-01 21:57:28 +00:00
|
|
|
if (run_command(&child))
|
2014-11-26 22:44:16 +00:00
|
|
|
return "Up-to-date check failed";
|
|
|
|
|
|
|
|
/* run_command() does not clean up completely; reinitialize */
|
|
|
|
child_process_init(&child);
|
2021-11-25 22:52:20 +00:00
|
|
|
strvec_pushl(&child.args, "diff-files", "--quiet",
|
|
|
|
"--ignore-submodules", "--", NULL);
|
2022-06-02 09:09:50 +00:00
|
|
|
strvec_pushv(&child.env, env->v);
|
2014-11-26 22:44:16 +00:00
|
|
|
child.dir = work_tree;
|
|
|
|
child.no_stdin = 1;
|
|
|
|
child.stdout_to_stderr = 1;
|
|
|
|
child.git_cmd = 1;
|
2014-12-01 21:57:28 +00:00
|
|
|
if (run_command(&child))
|
2014-11-26 22:44:16 +00:00
|
|
|
return "Working directory has unstaged changes";
|
|
|
|
|
|
|
|
child_process_init(&child);
|
2021-11-25 22:52:20 +00:00
|
|
|
strvec_pushl(&child.args, "diff-index", "--quiet", "--cached",
|
|
|
|
"--ignore-submodules",
|
|
|
|
/* diff-index with either HEAD or an empty tree */
|
|
|
|
head_has_history() ? "HEAD" : empty_tree_oid_hex(),
|
|
|
|
"--", NULL);
|
2022-06-02 09:09:50 +00:00
|
|
|
strvec_pushv(&child.env, env->v);
|
2014-11-26 22:44:16 +00:00
|
|
|
child.no_stdin = 1;
|
|
|
|
child.no_stdout = 1;
|
|
|
|
child.stdout_to_stderr = 0;
|
|
|
|
child.git_cmd = 1;
|
2014-12-01 21:57:28 +00:00
|
|
|
if (run_command(&child))
|
2014-11-26 22:44:16 +00:00
|
|
|
return "Working directory has staged changes";
|
|
|
|
|
|
|
|
child_process_init(&child);
|
2021-11-25 22:52:20 +00:00
|
|
|
strvec_pushl(&child.args, "read-tree", "-u", "-m", hash_to_hex(sha1),
|
|
|
|
NULL);
|
2022-06-02 09:09:50 +00:00
|
|
|
strvec_pushv(&child.env, env->v);
|
2014-11-26 22:44:16 +00:00
|
|
|
child.dir = work_tree;
|
|
|
|
child.no_stdin = 1;
|
|
|
|
child.no_stdout = 1;
|
|
|
|
child.stdout_to_stderr = 0;
|
|
|
|
child.git_cmd = 1;
|
2014-12-01 21:57:28 +00:00
|
|
|
if (run_command(&child))
|
2014-11-26 22:44:16 +00:00
|
|
|
return "Could not update working tree to new HEAD";
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2014-12-01 23:29:54 +00:00
|
|
|
static const char *push_to_checkout_hook = "push-to-checkout";
|
|
|
|
|
2019-08-18 20:04:24 +00:00
|
|
|
static const char *push_to_checkout(unsigned char *hash,
|
hooks: fix an obscure TOCTOU "did we just run a hook?" race
Fix a Time-of-check to time-of-use (TOCTOU) race in code added in
680ee550d72 (commit: skip discarding the index if there is no
pre-commit hook, 2017-08-14).
This obscure race condition can occur if we e.g. ran the "pre-commit"
hook and it modified the index, but hook_exists() returns false later
on (e.g., because the hook itself went away, the directory became
unreadable, etc.). Then we won't call discard_cache() when we should
have.
The race condition itself probably doesn't matter, and users would
have been unlikely to run into it in practice. This problem has been
noted on-list when 680ee550d72 was discussed[1], but had not been
fixed.
This change is mainly intended to improve the readability of the code
involved, and to make reasoning about it more straightforward. It
wasn't as obvious what we were trying to do here, but by having an
"invoked_hook" it's clearer that e.g. our discard_cache() is happening
because of the earlier hook execution.
Let's also change this for the push-to-checkout hook. Now instead of
checking if the hook exists and either doing a push to checkout or a
push to deploy we'll always attempt a push to checkout. If the hook
doesn't exist we'll fall back on push to deploy. The same behavior as
before, without the TOCTOU race. See 0855331941b (receive-pack:
support push-to-checkout hook, 2014-12-01) for the introduction of the
previous behavior.
This leaves uses of hook_exists() in two places that matter. The
"reference-transaction" check in refs.c, see 67541597670 (refs:
implement reference transaction hook, 2020-06-19), and the
"prepare-commit-msg" hook, see 66618a50f9c (sequencer: run
'prepare-commit-msg' hook, 2018-01-24).
In both of those cases we're saving ourselves CPU time by not
preparing data for the hook that we'll then do nothing with if we
don't have the hook. So using this "invoked_hook" pattern doesn't make
sense in those cases.
The "reference-transaction" and "prepare-commit-msg" hook also aren't
racy. In those cases we'll skip the hook runs if we race with a new
hook being added, whereas in the TOCTOU races being fixed here we were
incorrectly skipping the required post-hook logic.
1. https://lore.kernel.org/git/20170810191613.kpmhzg4seyxy3cpq@sigill.intra.peff.net/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-07 12:33:46 +00:00
|
|
|
int *invoked_hook,
|
2020-07-28 20:24:27 +00:00
|
|
|
struct strvec *env,
|
2014-12-01 23:29:54 +00:00
|
|
|
const char *work_tree)
|
|
|
|
{
|
2021-12-22 03:59:42 +00:00
|
|
|
struct run_hooks_opt opt = RUN_HOOKS_OPT_INIT;
|
hooks: fix an obscure TOCTOU "did we just run a hook?" race
Fix a Time-of-check to time-of-use (TOCTOU) race in code added in
680ee550d72 (commit: skip discarding the index if there is no
pre-commit hook, 2017-08-14).
This obscure race condition can occur if we e.g. ran the "pre-commit"
hook and it modified the index, but hook_exists() returns false later
on (e.g., because the hook itself went away, the directory became
unreadable, etc.). Then we won't call discard_cache() when we should
have.
The race condition itself probably doesn't matter, and users would
have been unlikely to run into it in practice. This problem has been
noted on-list when 680ee550d72 was discussed[1], but had not been
fixed.
This change is mainly intended to improve the readability of the code
involved, and to make reasoning about it more straightforward. It
wasn't as obvious what we were trying to do here, but by having an
"invoked_hook" it's clearer that e.g. our discard_cache() is happening
because of the earlier hook execution.
Let's also change this for the push-to-checkout hook. Now instead of
checking if the hook exists and either doing a push to checkout or a
push to deploy we'll always attempt a push to checkout. If the hook
doesn't exist we'll fall back on push to deploy. The same behavior as
before, without the TOCTOU race. See 0855331941b (receive-pack:
support push-to-checkout hook, 2014-12-01) for the introduction of the
previous behavior.
This leaves uses of hook_exists() in two places that matter. The
"reference-transaction" check in refs.c, see 67541597670 (refs:
implement reference transaction hook, 2020-06-19), and the
"prepare-commit-msg" hook, see 66618a50f9c (sequencer: run
'prepare-commit-msg' hook, 2018-01-24).
In both of those cases we're saving ourselves CPU time by not
preparing data for the hook that we'll then do nothing with if we
don't have the hook. So using this "invoked_hook" pattern doesn't make
sense in those cases.
The "reference-transaction" and "prepare-commit-msg" hook also aren't
racy. In those cases we'll skip the hook runs if we race with a new
hook being added, whereas in the TOCTOU races being fixed here we were
incorrectly skipping the required post-hook logic.
1. https://lore.kernel.org/git/20170810191613.kpmhzg4seyxy3cpq@sigill.intra.peff.net/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-07 12:33:46 +00:00
|
|
|
opt.invoked_hook = invoked_hook;
|
2021-12-22 03:59:42 +00:00
|
|
|
|
2020-07-28 20:24:27 +00:00
|
|
|
strvec_pushf(env, "GIT_WORK_TREE=%s", absolute_path(work_tree));
|
2021-12-22 03:59:42 +00:00
|
|
|
strvec_pushv(&opt.env, env->v);
|
|
|
|
strvec_push(&opt.args, hash_to_hex(hash));
|
|
|
|
if (run_hooks_opt(push_to_checkout_hook, &opt))
|
2014-12-01 23:29:54 +00:00
|
|
|
return "push-to-checkout hook declined";
|
|
|
|
else
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
receive.denyCurrentBranch: respect all worktrees
The receive.denyCurrentBranch config option controls what happens if
you push to a branch that is checked out into a non-bare repository.
By default, it rejects it. It can be disabled via `ignore` or `warn`.
Another yet trickier option is `updateInstead`.
However, this setting was forgotten when the git worktree command was
introduced: only the main worktree's current branch is respected.
With this change, all worktrees are respected.
That change also leads to revealing another bug,
i.e. `receive.denyCurrentBranch = true` was ignored when pushing into a
non-bare repository's unborn current branch using ref namespaces. As
`is_ref_checked_out()` returns 0 which means `receive-pack` does not get
into conditional statement to switch `deny_current_branch` accordingly
(ignore, warn, refuse, unconfigured, updateInstead).
receive.denyCurrentBranch uses the function `refs_resolve_ref_unsafe()`
(called via `resolve_refdup()`) to resolve the symbolic ref HEAD, but
that function fails when HEAD does not point at a valid commit.
As we replace the call to `refs_resolve_ref_unsafe()` with
`find_shared_symref()`, which has no problem finding the worktree for a
given branch even if it is unborn yet, this bug is fixed at the same
time: receive.denyCurrentBranch now also handles worktrees with unborn
branches as intended even while using ref namespaces.
Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Hariom Verma <hariom18599@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-23 18:57:10 +00:00
|
|
|
static const char *update_worktree(unsigned char *sha1, const struct worktree *worktree)
|
2014-12-01 21:57:28 +00:00
|
|
|
{
|
2021-12-01 22:15:45 +00:00
|
|
|
const char *retval, *git_dir;
|
2020-07-28 20:24:27 +00:00
|
|
|
struct strvec env = STRVEC_INIT;
|
hooks: fix an obscure TOCTOU "did we just run a hook?" race
Fix a Time-of-check to time-of-use (TOCTOU) race in code added in
680ee550d72 (commit: skip discarding the index if there is no
pre-commit hook, 2017-08-14).
This obscure race condition can occur if we e.g. ran the "pre-commit"
hook and it modified the index, but hook_exists() returns false later
on (e.g., because the hook itself went away, the directory became
unreadable, etc.). Then we won't call discard_cache() when we should
have.
The race condition itself probably doesn't matter, and users would
have been unlikely to run into it in practice. This problem has been
noted on-list when 680ee550d72 was discussed[1], but had not been
fixed.
This change is mainly intended to improve the readability of the code
involved, and to make reasoning about it more straightforward. It
wasn't as obvious what we were trying to do here, but by having an
"invoked_hook" it's clearer that e.g. our discard_cache() is happening
because of the earlier hook execution.
Let's also change this for the push-to-checkout hook. Now instead of
checking if the hook exists and either doing a push to checkout or a
push to deploy we'll always attempt a push to checkout. If the hook
doesn't exist we'll fall back on push to deploy. The same behavior as
before, without the TOCTOU race. See 0855331941b (receive-pack:
support push-to-checkout hook, 2014-12-01) for the introduction of the
previous behavior.
This leaves uses of hook_exists() in two places that matter. The
"reference-transaction" check in refs.c, see 67541597670 (refs:
implement reference transaction hook, 2020-06-19), and the
"prepare-commit-msg" hook, see 66618a50f9c (sequencer: run
'prepare-commit-msg' hook, 2018-01-24).
In both of those cases we're saving ourselves CPU time by not
preparing data for the hook that we'll then do nothing with if we
don't have the hook. So using this "invoked_hook" pattern doesn't make
sense in those cases.
The "reference-transaction" and "prepare-commit-msg" hook also aren't
racy. In those cases we'll skip the hook runs if we race with a new
hook being added, whereas in the TOCTOU races being fixed here we were
incorrectly skipping the required post-hook logic.
1. https://lore.kernel.org/git/20170810191613.kpmhzg4seyxy3cpq@sigill.intra.peff.net/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-07 12:33:46 +00:00
|
|
|
int invoked_hook;
|
2014-12-01 21:57:28 +00:00
|
|
|
|
2021-12-01 22:15:45 +00:00
|
|
|
if (!worktree || !worktree->path)
|
|
|
|
BUG("worktree->path must be non-NULL");
|
receive.denyCurrentBranch: respect all worktrees
The receive.denyCurrentBranch config option controls what happens if
you push to a branch that is checked out into a non-bare repository.
By default, it rejects it. It can be disabled via `ignore` or `warn`.
Another yet trickier option is `updateInstead`.
However, this setting was forgotten when the git worktree command was
introduced: only the main worktree's current branch is respected.
With this change, all worktrees are respected.
That change also leads to revealing another bug,
i.e. `receive.denyCurrentBranch = true` was ignored when pushing into a
non-bare repository's unborn current branch using ref namespaces. As
`is_ref_checked_out()` returns 0 which means `receive-pack` does not get
into conditional statement to switch `deny_current_branch` accordingly
(ignore, warn, refuse, unconfigured, updateInstead).
receive.denyCurrentBranch uses the function `refs_resolve_ref_unsafe()`
(called via `resolve_refdup()`) to resolve the symbolic ref HEAD, but
that function fails when HEAD does not point at a valid commit.
As we replace the call to `refs_resolve_ref_unsafe()` with
`find_shared_symref()`, which has no problem finding the worktree for a
given branch even if it is unborn yet, this bug is fixed at the same
time: receive.denyCurrentBranch now also handles worktrees with unborn
branches as intended even while using ref namespaces.
Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Hariom Verma <hariom18599@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-23 18:57:10 +00:00
|
|
|
|
2021-12-01 22:15:46 +00:00
|
|
|
if (worktree->is_bare)
|
2014-12-01 21:57:28 +00:00
|
|
|
return "denyCurrentBranch = updateInstead needs a worktree";
|
2021-12-01 22:15:45 +00:00
|
|
|
git_dir = get_worktree_git_dir(worktree);
|
2014-12-01 21:57:28 +00:00
|
|
|
|
2020-07-28 20:24:27 +00:00
|
|
|
strvec_pushf(&env, "GIT_DIR=%s", absolute_path(git_dir));
|
2014-12-01 21:57:28 +00:00
|
|
|
|
hooks: fix an obscure TOCTOU "did we just run a hook?" race
Fix a Time-of-check to time-of-use (TOCTOU) race in code added in
680ee550d72 (commit: skip discarding the index if there is no
pre-commit hook, 2017-08-14).
This obscure race condition can occur if we e.g. ran the "pre-commit"
hook and it modified the index, but hook_exists() returns false later
on (e.g., because the hook itself went away, the directory became
unreadable, etc.). Then we won't call discard_cache() when we should
have.
The race condition itself probably doesn't matter, and users would
have been unlikely to run into it in practice. This problem has been
noted on-list when 680ee550d72 was discussed[1], but had not been
fixed.
This change is mainly intended to improve the readability of the code
involved, and to make reasoning about it more straightforward. It
wasn't as obvious what we were trying to do here, but by having an
"invoked_hook" it's clearer that e.g. our discard_cache() is happening
because of the earlier hook execution.
Let's also change this for the push-to-checkout hook. Now instead of
checking if the hook exists and either doing a push to checkout or a
push to deploy we'll always attempt a push to checkout. If the hook
doesn't exist we'll fall back on push to deploy. The same behavior as
before, without the TOCTOU race. See 0855331941b (receive-pack:
support push-to-checkout hook, 2014-12-01) for the introduction of the
previous behavior.
This leaves uses of hook_exists() in two places that matter. The
"reference-transaction" check in refs.c, see 67541597670 (refs:
implement reference transaction hook, 2020-06-19), and the
"prepare-commit-msg" hook, see 66618a50f9c (sequencer: run
'prepare-commit-msg' hook, 2018-01-24).
In both of those cases we're saving ourselves CPU time by not
preparing data for the hook that we'll then do nothing with if we
don't have the hook. So using this "invoked_hook" pattern doesn't make
sense in those cases.
The "reference-transaction" and "prepare-commit-msg" hook also aren't
racy. In those cases we'll skip the hook runs if we race with a new
hook being added, whereas in the TOCTOU races being fixed here we were
incorrectly skipping the required post-hook logic.
1. https://lore.kernel.org/git/20170810191613.kpmhzg4seyxy3cpq@sigill.intra.peff.net/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-07 12:33:46 +00:00
|
|
|
retval = push_to_checkout(sha1, &invoked_hook, &env, worktree->path);
|
|
|
|
if (!invoked_hook)
|
2021-12-01 22:15:45 +00:00
|
|
|
retval = push_to_deploy(sha1, &env, worktree->path);
|
2014-12-01 21:57:28 +00:00
|
|
|
|
2020-07-28 20:24:27 +00:00
|
|
|
strvec_clear(&env);
|
2014-12-01 21:57:28 +00:00
|
|
|
return retval;
|
|
|
|
}
|
|
|
|
|
2013-12-05 13:02:47 +00:00
|
|
|
static const char *update(struct command *cmd, struct shallow_info *si)
|
2005-06-30 17:15:22 +00:00
|
|
|
{
|
2005-12-26 07:18:37 +00:00
|
|
|
const char *name = cmd->ref_name;
|
2011-07-08 23:13:32 +00:00
|
|
|
struct strbuf namespaced_name_buf = STRBUF_INIT;
|
2017-05-04 13:57:55 +00:00
|
|
|
static char *namespaced_name;
|
|
|
|
const char *ret;
|
2017-03-26 16:01:29 +00:00
|
|
|
struct object_id *old_oid = &cmd->old_oid;
|
|
|
|
struct object_id *new_oid = &cmd->new_oid;
|
2018-10-19 04:57:35 +00:00
|
|
|
int do_update_worktree = 0;
|
2021-12-01 22:15:43 +00:00
|
|
|
struct worktree **worktrees = get_worktrees();
|
|
|
|
const struct worktree *worktree =
|
2021-12-01 22:15:46 +00:00
|
|
|
find_shared_symref(worktrees, "HEAD", name);
|
2005-06-30 17:15:22 +00:00
|
|
|
|
2008-01-04 19:37:17 +00:00
|
|
|
/* only refs/... are allowed */
|
push: allow delete single-level ref
We discourage the creation/update of single-level refs
because some upper-layer applications only work in specified
reference namespaces, such as "refs/heads/*" or "refs/tags/*",
these single-level refnames may not be recognized. However,
we still hope users can delete them which have been created
by mistake.
Therefore, when updating branches on the server with
"git receive-pack", by checking whether it is a branch deletion
operation, it will determine whether to allow the update of
a single-level refs. This avoids creating/updating such
single-level refs, but allows them to be deleted.
On the client side, "git push" also does not properly fill in
the old-oid of single-level refs, which causes the server-side
"git receive-pack" to think that the ref's old-oid has changed
when deleting single-level refs, this causes the push to be
rejected. So the solution is to fix the client to be able to
delete single-level refs by properly filling old-oid.
Signed-off-by: ZheNing Hu <adlternative@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-01 10:20:29 +00:00
|
|
|
if (!starts_with(name, "refs/") ||
|
|
|
|
check_refname_format(name + 5, is_null_oid(new_oid) ?
|
|
|
|
REFNAME_ALLOW_ONELEVEL : 0)) {
|
2023-03-01 10:20:28 +00:00
|
|
|
rp_error("refusing to update funny ref '%s' remotely", name);
|
2021-12-01 22:15:43 +00:00
|
|
|
ret = "funny refname";
|
|
|
|
goto out;
|
2005-12-26 07:18:37 +00:00
|
|
|
}
|
2005-10-14 01:57:39 +00:00
|
|
|
|
2011-07-08 23:13:32 +00:00
|
|
|
strbuf_addf(&namespaced_name_buf, "%s%s", get_git_namespace(), name);
|
2017-05-04 13:57:55 +00:00
|
|
|
free(namespaced_name);
|
2011-07-08 23:13:32 +00:00
|
|
|
namespaced_name = strbuf_detach(&namespaced_name_buf, NULL);
|
|
|
|
|
2021-12-01 22:15:46 +00:00
|
|
|
if (worktree && !worktree->is_bare) {
|
2009-02-01 01:34:05 +00:00
|
|
|
switch (deny_current_branch) {
|
|
|
|
case DENY_IGNORE:
|
2008-11-09 01:49:27 +00:00
|
|
|
break;
|
2009-02-01 01:34:05 +00:00
|
|
|
case DENY_WARN:
|
2010-02-10 17:34:12 +00:00
|
|
|
rp_warning("updating the current branch");
|
2008-11-09 01:49:27 +00:00
|
|
|
break;
|
2009-02-01 01:34:05 +00:00
|
|
|
case DENY_REFUSE:
|
2009-02-11 10:28:03 +00:00
|
|
|
case DENY_UNCONFIGURED:
|
2010-02-10 17:34:12 +00:00
|
|
|
rp_error("refusing to update checked out branch: %s", name);
|
2009-02-11 10:28:03 +00:00
|
|
|
if (deny_current_branch == DENY_UNCONFIGURED)
|
|
|
|
refuse_unconfigured_deny();
|
2021-12-01 22:15:43 +00:00
|
|
|
ret = "branch is currently checked out";
|
|
|
|
goto out;
|
2014-11-26 22:44:16 +00:00
|
|
|
case DENY_UPDATE_INSTEAD:
|
2018-10-19 04:57:35 +00:00
|
|
|
/* pass -- let other checks intervene first */
|
|
|
|
do_update_worktree = 1;
|
2014-11-26 22:44:16 +00:00
|
|
|
break;
|
2009-02-01 01:34:05 +00:00
|
|
|
}
|
2008-11-09 01:49:27 +00:00
|
|
|
}
|
|
|
|
|
2023-03-28 13:58:50 +00:00
|
|
|
if (!is_null_oid(new_oid) && !repo_has_object_file(the_repository, new_oid)) {
|
2007-03-07 21:51:59 +00:00
|
|
|
error("unpack should have generated %s, "
|
2017-03-26 16:01:29 +00:00
|
|
|
"but I can't find it!", oid_to_hex(new_oid));
|
2021-12-01 22:15:43 +00:00
|
|
|
ret = "bad pack";
|
|
|
|
goto out;
|
2005-12-26 07:18:37 +00:00
|
|
|
}
|
2009-02-09 06:31:21 +00:00
|
|
|
|
2017-03-26 16:01:29 +00:00
|
|
|
if (!is_null_oid(old_oid) && is_null_oid(new_oid)) {
|
2013-11-30 20:55:40 +00:00
|
|
|
if (deny_deletes && starts_with(name, "refs/heads/")) {
|
2010-02-10 17:34:12 +00:00
|
|
|
rp_error("denying ref deletion for %s", name);
|
2021-12-01 22:15:43 +00:00
|
|
|
ret = "deletion prohibited";
|
|
|
|
goto out;
|
2009-02-09 06:31:21 +00:00
|
|
|
}
|
|
|
|
|
receive.denyCurrentBranch: respect all worktrees
The receive.denyCurrentBranch config option controls what happens if
you push to a branch that is checked out into a non-bare repository.
By default, it rejects it. It can be disabled via `ignore` or `warn`.
Another yet trickier option is `updateInstead`.
However, this setting was forgotten when the git worktree command was
introduced: only the main worktree's current branch is respected.
With this change, all worktrees are respected.
That change also leads to revealing another bug,
i.e. `receive.denyCurrentBranch = true` was ignored when pushing into a
non-bare repository's unborn current branch using ref namespaces. As
`is_ref_checked_out()` returns 0 which means `receive-pack` does not get
into conditional statement to switch `deny_current_branch` accordingly
(ignore, warn, refuse, unconfigured, updateInstead).
receive.denyCurrentBranch uses the function `refs_resolve_ref_unsafe()`
(called via `resolve_refdup()`) to resolve the symbolic ref HEAD, but
that function fails when HEAD does not point at a valid commit.
As we replace the call to `refs_resolve_ref_unsafe()` with
`find_shared_symref()`, which has no problem finding the worktree for a
given branch even if it is unborn yet, this bug is fixed at the same
time: receive.denyCurrentBranch now also handles worktrees with unborn
branches as intended even while using ref namespaces.
Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Hariom Verma <hariom18599@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-23 18:57:10 +00:00
|
|
|
if (worktree || (head_name && !strcmp(namespaced_name, head_name))) {
|
2009-02-09 06:31:21 +00:00
|
|
|
switch (deny_delete_current) {
|
|
|
|
case DENY_IGNORE:
|
|
|
|
break;
|
|
|
|
case DENY_WARN:
|
2010-02-10 17:34:12 +00:00
|
|
|
rp_warning("deleting the current branch");
|
2009-02-09 06:31:21 +00:00
|
|
|
break;
|
|
|
|
case DENY_REFUSE:
|
2009-02-09 08:19:46 +00:00
|
|
|
case DENY_UNCONFIGURED:
|
2014-11-26 22:44:16 +00:00
|
|
|
case DENY_UPDATE_INSTEAD:
|
2009-02-09 08:19:46 +00:00
|
|
|
if (deny_delete_current == DENY_UNCONFIGURED)
|
|
|
|
refuse_unconfigured_deny_delete_current();
|
2010-02-10 17:34:12 +00:00
|
|
|
rp_error("refusing to delete the current branch: %s", name);
|
2021-12-01 22:15:43 +00:00
|
|
|
ret = "deletion of the current branch prohibited";
|
|
|
|
goto out;
|
2014-11-26 22:44:16 +00:00
|
|
|
default:
|
2021-12-01 22:15:43 +00:00
|
|
|
ret = "Invalid denyDeleteCurrent setting";
|
|
|
|
goto out;
|
2009-02-09 06:31:21 +00:00
|
|
|
}
|
|
|
|
}
|
2008-11-01 14:42:16 +00:00
|
|
|
}
|
2009-02-09 06:31:21 +00:00
|
|
|
|
2017-03-26 16:01:29 +00:00
|
|
|
if (deny_non_fast_forwards && !is_null_oid(new_oid) &&
|
|
|
|
!is_null_oid(old_oid) &&
|
2013-11-30 20:55:40 +00:00
|
|
|
starts_with(name, "refs/heads/")) {
|
2008-01-02 07:39:21 +00:00
|
|
|
struct object *old_object, *new_object;
|
2006-09-20 23:07:54 +00:00
|
|
|
struct commit *old_commit, *new_commit;
|
|
|
|
|
2018-06-29 01:21:51 +00:00
|
|
|
old_object = parse_object(the_repository, old_oid);
|
|
|
|
new_object = parse_object(the_repository, new_oid);
|
2008-01-02 07:39:21 +00:00
|
|
|
|
|
|
|
if (!old_object || !new_object ||
|
|
|
|
old_object->type != OBJ_COMMIT ||
|
|
|
|
new_object->type != OBJ_COMMIT) {
|
|
|
|
error("bad sha1 objects for %s", name);
|
2021-12-01 22:15:43 +00:00
|
|
|
ret = "bad ref";
|
|
|
|
goto out;
|
2008-01-02 07:39:21 +00:00
|
|
|
}
|
|
|
|
old_commit = (struct commit *)old_object;
|
|
|
|
new_commit = (struct commit *)new_object;
|
2023-03-28 13:58:47 +00:00
|
|
|
if (!repo_in_merge_bases(the_repository, old_commit, new_commit)) {
|
2010-02-10 17:34:12 +00:00
|
|
|
rp_error("denying non-fast-forward %s"
|
|
|
|
" (you should pull first)", name);
|
2021-12-01 22:15:43 +00:00
|
|
|
ret = "non-fast-forward";
|
|
|
|
goto out;
|
2007-03-07 21:51:59 +00:00
|
|
|
}
|
2006-09-20 23:07:54 +00:00
|
|
|
}
|
2007-03-10 08:28:13 +00:00
|
|
|
if (run_update_hook(cmd)) {
|
2010-02-10 17:34:12 +00:00
|
|
|
rp_error("hook declined to update %s", name);
|
2021-12-01 22:15:43 +00:00
|
|
|
ret = "hook declined";
|
|
|
|
goto out;
|
2005-07-31 19:17:43 +00:00
|
|
|
}
|
2006-09-27 09:40:06 +00:00
|
|
|
|
2018-10-19 04:57:35 +00:00
|
|
|
if (do_update_worktree) {
|
2021-12-01 22:15:45 +00:00
|
|
|
ret = update_worktree(new_oid->hash, worktree);
|
2018-10-19 04:57:35 +00:00
|
|
|
if (ret)
|
2021-12-01 22:15:43 +00:00
|
|
|
goto out;
|
2018-10-19 04:57:35 +00:00
|
|
|
}
|
|
|
|
|
2017-03-26 16:01:29 +00:00
|
|
|
if (is_null_oid(new_oid)) {
|
2015-01-08 03:23:18 +00:00
|
|
|
struct strbuf err = STRBUF_INIT;
|
2018-06-29 01:21:51 +00:00
|
|
|
if (!parse_object(the_repository, old_oid)) {
|
2017-03-26 16:01:29 +00:00
|
|
|
old_oid = NULL;
|
2011-09-28 15:39:35 +00:00
|
|
|
if (ref_exists(name)) {
|
2021-12-01 22:15:41 +00:00
|
|
|
rp_warning("allowing deletion of corrupt ref");
|
2011-09-28 15:39:35 +00:00
|
|
|
} else {
|
2021-12-01 22:15:41 +00:00
|
|
|
rp_warning("deleting a non-existent ref");
|
2011-09-28 15:39:35 +00:00
|
|
|
cmd->did_not_exist = 1;
|
|
|
|
}
|
2007-11-29 01:02:53 +00:00
|
|
|
}
|
2015-01-08 03:23:18 +00:00
|
|
|
if (ref_transaction_delete(transaction,
|
|
|
|
namespaced_name,
|
2017-10-15 22:06:53 +00:00
|
|
|
old_oid,
|
2015-02-17 17:00:16 +00:00
|
|
|
0, "push", &err)) {
|
2015-01-08 03:23:18 +00:00
|
|
|
rp_error("%s", err.buf);
|
2021-12-01 22:15:43 +00:00
|
|
|
ret = "failed to delete";
|
|
|
|
} else {
|
|
|
|
ret = NULL; /* good */
|
2006-11-24 08:26:49 +00:00
|
|
|
}
|
2015-01-08 03:23:18 +00:00
|
|
|
strbuf_release(&err);
|
2006-11-24 08:26:49 +00:00
|
|
|
}
|
|
|
|
else {
|
2014-04-28 21:36:15 +00:00
|
|
|
struct strbuf err = STRBUF_INIT;
|
2013-12-05 13:02:47 +00:00
|
|
|
if (shallow_update && si->shallow_ref[cmd->index] &&
|
2021-12-01 22:15:43 +00:00
|
|
|
update_shallow_ref(cmd, si)) {
|
|
|
|
ret = "shallow error";
|
|
|
|
goto out;
|
|
|
|
}
|
2013-12-05 13:02:47 +00:00
|
|
|
|
2015-01-08 03:23:18 +00:00
|
|
|
if (ref_transaction_update(transaction,
|
|
|
|
namespaced_name,
|
2017-10-15 22:06:53 +00:00
|
|
|
new_oid, old_oid,
|
2015-02-17 17:00:15 +00:00
|
|
|
0, "push",
|
2015-01-08 03:23:18 +00:00
|
|
|
&err)) {
|
2014-04-28 21:36:15 +00:00
|
|
|
rp_error("%s", err.buf);
|
2021-12-01 22:15:43 +00:00
|
|
|
ret = "failed to update ref";
|
|
|
|
} else {
|
|
|
|
ret = NULL; /* good */
|
2007-03-07 17:04:24 +00:00
|
|
|
}
|
2014-04-28 21:36:15 +00:00
|
|
|
strbuf_release(&err);
|
2005-08-02 21:24:22 +00:00
|
|
|
}
|
2021-12-01 22:15:43 +00:00
|
|
|
|
|
|
|
out:
|
|
|
|
free_worktrees(worktrees);
|
|
|
|
return ret;
|
2005-06-30 17:15:22 +00:00
|
|
|
}
|
|
|
|
|
2010-04-19 22:08:30 +00:00
|
|
|
static void run_update_post_hook(struct command *commands)
|
2005-08-02 21:24:22 +00:00
|
|
|
{
|
2010-04-19 22:08:30 +00:00
|
|
|
struct command *cmd;
|
2014-08-19 19:09:35 +00:00
|
|
|
struct child_process proc = CHILD_PROCESS_INIT;
|
2014-11-30 08:24:27 +00:00
|
|
|
const char *hook;
|
2005-08-02 21:24:22 +00:00
|
|
|
|
2013-01-13 05:17:02 +00:00
|
|
|
hook = find_hook("post-update");
|
2017-03-17 22:02:13 +00:00
|
|
|
if (!hook)
|
2007-03-07 21:50:43 +00:00
|
|
|
return;
|
2013-01-13 05:17:02 +00:00
|
|
|
|
2016-02-22 22:44:21 +00:00
|
|
|
for (cmd = commands; cmd; cmd = cmd->next) {
|
2011-09-28 15:39:35 +00:00
|
|
|
if (cmd->error_string || cmd->did_not_exist)
|
2005-08-02 21:24:22 +00:00
|
|
|
continue;
|
2020-07-29 00:37:20 +00:00
|
|
|
if (!proc.args.nr)
|
2020-07-28 20:24:27 +00:00
|
|
|
strvec_push(&proc.args, hook);
|
|
|
|
strvec_push(&proc.args, cmd->ref_name);
|
2005-08-02 21:24:22 +00:00
|
|
|
}
|
2020-07-29 00:37:20 +00:00
|
|
|
if (!proc.args.nr)
|
2017-03-17 22:02:13 +00:00
|
|
|
return;
|
2010-02-05 20:57:42 +00:00
|
|
|
|
|
|
|
proc.no_stdin = 1;
|
|
|
|
proc.stdout_to_stderr = 1;
|
|
|
|
proc.err = use_sideband ? -1 : 0;
|
2019-02-22 22:25:06 +00:00
|
|
|
proc.trace2_hook_name = "post-update";
|
2010-02-05 20:57:42 +00:00
|
|
|
|
|
|
|
if (!start_command(&proc)) {
|
|
|
|
if (use_sideband)
|
|
|
|
copy_to_sideband(proc.err, -1, NULL);
|
|
|
|
finish_command(&proc);
|
|
|
|
}
|
2005-08-02 21:24:22 +00:00
|
|
|
}
|
2005-06-30 17:15:22 +00:00
|
|
|
|
receive-pack: fix use-after-free bug
The resolve_ref_unsafe() function can, and sometimes will in the case
of this codepath, return the char * passed to it to the caller. In
this case we construct a strbuf, free it, and then continue using the
dst_name after that free().
The code being fixed dates back to da3efdb17b ("receive-pack: detect
aliased updates which can occur with symrefs", 2010-04-19). When it
was originally added it didn't have this bug, it was introduced when
it was subsequently modified to use strbuf in 6b01ecfe22 ("ref
namespaces: Support remote repositories via upload-pack and
receive-pack", 2011-07-08).
This is theoretically a security issue, the C standard makes no
guarantees that a value you use after free() hasn't been poked at or
changed by something else on the system, but in practice modern OSs
will have mapped the relevant page to this process, so nothing else
would have used it. We do no further allocations between the free()
and use-after-free, so we ourselves didn't corrupt or change the
value.
Jeff investigated that and found: "It probably would be an issue if
the allocation were larger. glibc at least will use mmap()/munmap()
after some cutoff[1], in which case we'd get a segfault from hitting
the unmapped page. But for small allocations, it just bumps brk() and
the memory is still available for further allocations after
free(). [...] If you had a sufficiently large refname you might be
able to trigger the bug [...]. I tried to push such a ref. I had to
manually make a packed-refs file with the long name to avoid
filesystem limits (though probably you could have a long a/b/c/ name
on ext4). But the result can't actually be pushed, because it all has
to fit into a 64k pkt-line as part of the push protocol.".
An a alternative and more succinct way of implementing this would have
been to do the strbuf_release() at the end of check_aliased_update()
and use "goto out" instead of the early "return" statements. Hopefully
this approach of using a helper instead makes it easier to follow.
1. Jeff: "Weirdly, the mmap() cutoff on my glibc system is 135168
bytes. Which is...2^17 + 2^12? 33 pages? I'm sure there's a good
reason for that, but I didn't dig into it."
Reported-by: 王健强 <jianqiang.wang@securitygossip.com>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-20 00:00:33 +00:00
|
|
|
static void check_aliased_update_internal(struct command *cmd,
|
|
|
|
struct string_list *list,
|
|
|
|
const char *dst_name, int flag)
|
2010-04-19 22:19:18 +00:00
|
|
|
{
|
|
|
|
struct string_list_item *item;
|
|
|
|
struct command *dst_cmd;
|
|
|
|
|
|
|
|
if (!(flag & REF_ISSYMREF))
|
|
|
|
return;
|
|
|
|
|
2011-07-08 23:13:32 +00:00
|
|
|
if (!dst_name) {
|
|
|
|
rp_error("refusing update to broken symref '%s'", cmd->ref_name);
|
|
|
|
cmd->skip_update = 1;
|
|
|
|
cmd->error_string = "broken symref";
|
|
|
|
return;
|
|
|
|
}
|
2016-04-07 19:03:08 +00:00
|
|
|
dst_name = strip_namespace(dst_name);
|
2011-07-08 23:13:32 +00:00
|
|
|
|
2022-05-02 16:50:37 +00:00
|
|
|
if (!(item = string_list_lookup(list, dst_name)))
|
2010-04-19 22:19:18 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
cmd->skip_update = 1;
|
|
|
|
|
|
|
|
dst_cmd = (struct command *) item->util;
|
|
|
|
|
convert "oidcmp() == 0" to oideq()
Using the more restrictive oideq() should, in the long run,
give the compiler more opportunities to optimize these
callsites. For now, this conversion should be a complete
noop with respect to the generated code.
The result is also perhaps a little more readable, as it
avoids the "zero is equal" idiom. Since it's so prevalent in
C, I think seasoned programmers tend not to even notice it
anymore, but it can sometimes make for awkward double
negations (e.g., we can drop a few !!oidcmp() instances
here).
This patch was generated almost entirely by the included
coccinelle patch. This mechanical conversion should be
completely safe, because we check explicitly for cases where
oidcmp() is compared to 0, which is what oideq() is doing
under the hood. Note that we don't have to catch "!oidcmp()"
separately; coccinelle's standard isomorphisms make sure the
two are treated equivalently.
I say "almost" because I did hand-edit the coccinelle output
to fix up a few style violations (it mostly keeps the
original formatting, but sometimes unwraps long lines).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-28 21:22:40 +00:00
|
|
|
if (oideq(&cmd->old_oid, &dst_cmd->old_oid) &&
|
|
|
|
oideq(&cmd->new_oid, &dst_cmd->new_oid))
|
2010-04-19 22:19:18 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
dst_cmd->skip_update = 1;
|
|
|
|
|
|
|
|
rp_error("refusing inconsistent update between symref '%s' (%s..%s) and"
|
|
|
|
" its target '%s' (%s..%s)",
|
2016-10-20 06:19:19 +00:00
|
|
|
cmd->ref_name,
|
2023-03-28 13:58:46 +00:00
|
|
|
repo_find_unique_abbrev(the_repository, &cmd->old_oid, DEFAULT_ABBREV),
|
|
|
|
repo_find_unique_abbrev(the_repository, &cmd->new_oid, DEFAULT_ABBREV),
|
2016-10-20 06:19:19 +00:00
|
|
|
dst_cmd->ref_name,
|
2023-03-28 13:58:46 +00:00
|
|
|
repo_find_unique_abbrev(the_repository, &dst_cmd->old_oid, DEFAULT_ABBREV),
|
|
|
|
repo_find_unique_abbrev(the_repository, &dst_cmd->new_oid, DEFAULT_ABBREV));
|
2010-04-19 22:19:18 +00:00
|
|
|
|
|
|
|
cmd->error_string = dst_cmd->error_string =
|
|
|
|
"inconsistent aliased update";
|
|
|
|
}
|
|
|
|
|
receive-pack: fix use-after-free bug
The resolve_ref_unsafe() function can, and sometimes will in the case
of this codepath, return the char * passed to it to the caller. In
this case we construct a strbuf, free it, and then continue using the
dst_name after that free().
The code being fixed dates back to da3efdb17b ("receive-pack: detect
aliased updates which can occur with symrefs", 2010-04-19). When it
was originally added it didn't have this bug, it was introduced when
it was subsequently modified to use strbuf in 6b01ecfe22 ("ref
namespaces: Support remote repositories via upload-pack and
receive-pack", 2011-07-08).
This is theoretically a security issue, the C standard makes no
guarantees that a value you use after free() hasn't been poked at or
changed by something else on the system, but in practice modern OSs
will have mapped the relevant page to this process, so nothing else
would have used it. We do no further allocations between the free()
and use-after-free, so we ourselves didn't corrupt or change the
value.
Jeff investigated that and found: "It probably would be an issue if
the allocation were larger. glibc at least will use mmap()/munmap()
after some cutoff[1], in which case we'd get a segfault from hitting
the unmapped page. But for small allocations, it just bumps brk() and
the memory is still available for further allocations after
free(). [...] If you had a sufficiently large refname you might be
able to trigger the bug [...]. I tried to push such a ref. I had to
manually make a packed-refs file with the long name to avoid
filesystem limits (though probably you could have a long a/b/c/ name
on ext4). But the result can't actually be pushed, because it all has
to fit into a 64k pkt-line as part of the push protocol.".
An a alternative and more succinct way of implementing this would have
been to do the strbuf_release() at the end of check_aliased_update()
and use "goto out" instead of the early "return" statements. Hopefully
this approach of using a helper instead makes it easier to follow.
1. Jeff: "Weirdly, the mmap() cutoff on my glibc system is 135168
bytes. Which is...2^17 + 2^12? 33 pages? I'm sure there's a good
reason for that, but I didn't dig into it."
Reported-by: 王健强 <jianqiang.wang@securitygossip.com>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-20 00:00:33 +00:00
|
|
|
static void check_aliased_update(struct command *cmd, struct string_list *list)
|
|
|
|
{
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
const char *dst_name;
|
|
|
|
int flag;
|
|
|
|
|
|
|
|
strbuf_addf(&buf, "%s%s", get_git_namespace(), cmd->ref_name);
|
|
|
|
dst_name = resolve_ref_unsafe(buf.buf, 0, NULL, &flag);
|
|
|
|
check_aliased_update_internal(cmd, list, dst_name, flag);
|
|
|
|
strbuf_release(&buf);
|
|
|
|
}
|
|
|
|
|
2010-04-19 22:19:18 +00:00
|
|
|
static void check_aliased_updates(struct command *commands)
|
|
|
|
{
|
|
|
|
struct command *cmd;
|
2010-07-04 19:46:19 +00:00
|
|
|
struct string_list ref_list = STRING_LIST_INIT_NODUP;
|
2010-04-19 22:19:18 +00:00
|
|
|
|
|
|
|
for (cmd = commands; cmd; cmd = cmd->next) {
|
|
|
|
struct string_list_item *item =
|
2010-06-25 23:41:38 +00:00
|
|
|
string_list_append(&ref_list, cmd->ref_name);
|
2010-04-19 22:19:18 +00:00
|
|
|
item->util = (void *)cmd;
|
|
|
|
}
|
2014-11-25 08:02:35 +00:00
|
|
|
string_list_sort(&ref_list);
|
2010-04-19 22:19:18 +00:00
|
|
|
|
2012-02-13 20:17:12 +00:00
|
|
|
for (cmd = commands; cmd; cmd = cmd->next) {
|
|
|
|
if (!cmd->error_string)
|
|
|
|
check_aliased_update(cmd, &ref_list);
|
|
|
|
}
|
2010-04-19 22:19:18 +00:00
|
|
|
|
|
|
|
string_list_clear(&ref_list, 0);
|
|
|
|
}
|
|
|
|
|
2021-09-01 13:09:50 +00:00
|
|
|
static const struct object_id *command_singleton_iterator(void *cb_data)
|
2011-09-02 23:52:08 +00:00
|
|
|
{
|
|
|
|
struct command **cmd_list = cb_data;
|
|
|
|
struct command *cmd = *cmd_list;
|
|
|
|
|
2017-03-26 16:01:29 +00:00
|
|
|
if (!cmd || is_null_oid(&cmd->new_oid))
|
2021-09-01 13:09:50 +00:00
|
|
|
return NULL;
|
2011-09-02 23:52:08 +00:00
|
|
|
*cmd_list = NULL; /* this returns only one */
|
2021-09-01 13:09:50 +00:00
|
|
|
return &cmd->new_oid;
|
2011-09-02 23:52:08 +00:00
|
|
|
}
|
|
|
|
|
2013-12-05 13:02:47 +00:00
|
|
|
static void set_connectivity_errors(struct command *commands,
|
|
|
|
struct shallow_info *si)
|
2011-09-02 23:52:08 +00:00
|
|
|
{
|
|
|
|
struct command *cmd;
|
|
|
|
|
|
|
|
for (cmd = commands; cmd; cmd = cmd->next) {
|
|
|
|
struct command *singleton = cmd;
|
2016-10-03 20:49:14 +00:00
|
|
|
struct check_connected_options opt = CHECK_CONNECTED_INIT;
|
|
|
|
|
2013-12-05 13:02:47 +00:00
|
|
|
if (shallow_update && si->shallow_ref[cmd->index])
|
|
|
|
/* to be checked in update_shallow_ref() */
|
|
|
|
continue;
|
2016-10-03 20:49:14 +00:00
|
|
|
|
|
|
|
opt.env = tmp_objdir_env(tmp_objdir);
|
check_everything_connected: use a struct with named options
The number of variants of check_everything_connected has
grown over the years, so that the "real" function takes
several possibly-zero, possibly-NULL arguments. We hid the
complexity behind some wrapper functions, but this doesn't
scale well when we want to add new options.
If we add more wrapper variants to handle the new options,
then we can get a combinatorial explosion when those options
might be used together (right now nobody wants to use both
"shallow" and "transport" together, so we get by with just a
few wrappers).
If instead we add new parameters to each function, each of
which can have a default value, then callers who want the
defaults end up with confusing invocations like:
check_everything_connected(fn, 0, data, -1, 0, NULL);
where it is unclear which parameter is which (and every
caller needs updated when we add new options).
Instead, let's add a struct to hold all of the optional
parameters. This is a little more verbose for the callers
(who have to declare the struct and fill it in), but it
makes their code much easier to follow, because every option
is named as it is set (and unused options do not have to be
mentioned at all).
Note that we could also stick the iteration function and its
callback data into the option struct, too. But since those
are required for each call, by avoiding doing so, we can let
very simple callers just pass "NULL" for the options and not
worry about the struct at all.
While we're touching each site, let's also rename the
function to check_connected(). The existing name was quite
long, and not all of the wrappers even used the full name.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-15 10:30:40 +00:00
|
|
|
if (!check_connected(command_singleton_iterator, &singleton,
|
2016-10-03 20:49:14 +00:00
|
|
|
&opt))
|
2011-09-02 23:52:08 +00:00
|
|
|
continue;
|
2016-10-03 20:49:14 +00:00
|
|
|
|
2011-09-02 23:52:08 +00:00
|
|
|
cmd->error_string = "missing necessary objects";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-12-05 13:02:47 +00:00
|
|
|
struct iterate_data {
|
|
|
|
struct command *cmds;
|
|
|
|
struct shallow_info *si;
|
|
|
|
};
|
|
|
|
|
2021-09-01 13:09:50 +00:00
|
|
|
static const struct object_id *iterate_receive_command_list(void *cb_data)
|
2011-09-02 23:52:08 +00:00
|
|
|
{
|
2013-12-05 13:02:47 +00:00
|
|
|
struct iterate_data *data = cb_data;
|
|
|
|
struct command **cmd_list = &data->cmds;
|
2011-09-02 23:52:08 +00:00
|
|
|
struct command *cmd = *cmd_list;
|
|
|
|
|
2013-12-05 13:02:47 +00:00
|
|
|
for (; cmd; cmd = cmd->next) {
|
|
|
|
if (shallow_update && data->si->shallow_ref[cmd->index])
|
|
|
|
/* to be checked in update_shallow_ref() */
|
|
|
|
continue;
|
2017-03-26 16:01:29 +00:00
|
|
|
if (!is_null_oid(&cmd->new_oid) && !cmd->skip_update) {
|
2011-11-03 19:15:08 +00:00
|
|
|
*cmd_list = cmd->next;
|
2021-09-01 13:09:50 +00:00
|
|
|
return &cmd->new_oid;
|
2011-11-03 19:15:08 +00:00
|
|
|
}
|
|
|
|
}
|
2021-09-01 13:09:50 +00:00
|
|
|
return NULL;
|
2011-09-02 23:52:08 +00:00
|
|
|
}
|
|
|
|
|
upload/receive-pack: allow hiding ref hierarchies
A repository may have refs that are only used for its internal
bookkeeping purposes that should not be exposed to the others that
come over the network.
Teach upload-pack to omit some refs from its initial advertisement
by paying attention to the uploadpack.hiderefs multi-valued
configuration variable. Do the same to receive-pack via the
receive.hiderefs variable. As a convenient short-hand, allow using
transfer.hiderefs to set the value to both of these variables.
Any ref that is under the hierarchies listed on the value of these
variable is excluded from responses to requests made by "ls-remote",
"fetch", etc. (for upload-pack) and "push" (for receive-pack).
Because these hidden refs do not count as OUR_REF, an attempt to
fetch objects at the tip of them will be rejected, and because these
refs do not get advertised, "git push :" will not see local branches
that have the same name as them as "matching" ones to be sent.
An attempt to update/delete these hidden refs with an explicit
refspec, e.g. "git push origin :refs/hidden/22", is rejected. This
is not a new restriction. To the pusher, it would appear that there
is no such ref, so its push request will conclude with "Now that I
sent you all the data, it is time for you to update the refs. I saw
that the ref did not exist when I started pushing, and I want the
result to point at this commit". The receiving end will apply the
compare-and-swap rule to this request and rejects the push with
"Well, your update request conflicts with somebody else; I see there
is such a ref.", which is the right thing to do. Otherwise a push to
a hidden ref will always be "the last one wins", which is not a good
default.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-19 00:08:30 +00:00
|
|
|
static void reject_updates_to_hidden(struct command *commands)
|
|
|
|
{
|
2015-11-03 07:58:16 +00:00
|
|
|
struct strbuf refname_full = STRBUF_INIT;
|
|
|
|
size_t prefix_len;
|
upload/receive-pack: allow hiding ref hierarchies
A repository may have refs that are only used for its internal
bookkeeping purposes that should not be exposed to the others that
come over the network.
Teach upload-pack to omit some refs from its initial advertisement
by paying attention to the uploadpack.hiderefs multi-valued
configuration variable. Do the same to receive-pack via the
receive.hiderefs variable. As a convenient short-hand, allow using
transfer.hiderefs to set the value to both of these variables.
Any ref that is under the hierarchies listed on the value of these
variable is excluded from responses to requests made by "ls-remote",
"fetch", etc. (for upload-pack) and "push" (for receive-pack).
Because these hidden refs do not count as OUR_REF, an attempt to
fetch objects at the tip of them will be rejected, and because these
refs do not get advertised, "git push :" will not see local branches
that have the same name as them as "matching" ones to be sent.
An attempt to update/delete these hidden refs with an explicit
refspec, e.g. "git push origin :refs/hidden/22", is rejected. This
is not a new restriction. To the pusher, it would appear that there
is no such ref, so its push request will conclude with "Now that I
sent you all the data, it is time for you to update the refs. I saw
that the ref did not exist when I started pushing, and I want the
result to point at this commit". The receiving end will apply the
compare-and-swap rule to this request and rejects the push with
"Well, your update request conflicts with somebody else; I see there
is such a ref.", which is the right thing to do. Otherwise a push to
a hidden ref will always be "the last one wins", which is not a good
default.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-19 00:08:30 +00:00
|
|
|
struct command *cmd;
|
|
|
|
|
2015-11-03 07:58:16 +00:00
|
|
|
strbuf_addstr(&refname_full, get_git_namespace());
|
|
|
|
prefix_len = refname_full.len;
|
|
|
|
|
upload/receive-pack: allow hiding ref hierarchies
A repository may have refs that are only used for its internal
bookkeeping purposes that should not be exposed to the others that
come over the network.
Teach upload-pack to omit some refs from its initial advertisement
by paying attention to the uploadpack.hiderefs multi-valued
configuration variable. Do the same to receive-pack via the
receive.hiderefs variable. As a convenient short-hand, allow using
transfer.hiderefs to set the value to both of these variables.
Any ref that is under the hierarchies listed on the value of these
variable is excluded from responses to requests made by "ls-remote",
"fetch", etc. (for upload-pack) and "push" (for receive-pack).
Because these hidden refs do not count as OUR_REF, an attempt to
fetch objects at the tip of them will be rejected, and because these
refs do not get advertised, "git push :" will not see local branches
that have the same name as them as "matching" ones to be sent.
An attempt to update/delete these hidden refs with an explicit
refspec, e.g. "git push origin :refs/hidden/22", is rejected. This
is not a new restriction. To the pusher, it would appear that there
is no such ref, so its push request will conclude with "Now that I
sent you all the data, it is time for you to update the refs. I saw
that the ref did not exist when I started pushing, and I want the
result to point at this commit". The receiving end will apply the
compare-and-swap rule to this request and rejects the push with
"Well, your update request conflicts with somebody else; I see there
is such a ref.", which is the right thing to do. Otherwise a push to
a hidden ref will always be "the last one wins", which is not a good
default.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-19 00:08:30 +00:00
|
|
|
for (cmd = commands; cmd; cmd = cmd->next) {
|
2015-11-03 07:58:16 +00:00
|
|
|
if (cmd->error_string)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
strbuf_setlen(&refname_full, prefix_len);
|
|
|
|
strbuf_addstr(&refname_full, cmd->ref_name);
|
|
|
|
|
2022-11-17 05:46:43 +00:00
|
|
|
if (!ref_is_hidden(cmd->ref_name, refname_full.buf, &hidden_refs))
|
upload/receive-pack: allow hiding ref hierarchies
A repository may have refs that are only used for its internal
bookkeeping purposes that should not be exposed to the others that
come over the network.
Teach upload-pack to omit some refs from its initial advertisement
by paying attention to the uploadpack.hiderefs multi-valued
configuration variable. Do the same to receive-pack via the
receive.hiderefs variable. As a convenient short-hand, allow using
transfer.hiderefs to set the value to both of these variables.
Any ref that is under the hierarchies listed on the value of these
variable is excluded from responses to requests made by "ls-remote",
"fetch", etc. (for upload-pack) and "push" (for receive-pack).
Because these hidden refs do not count as OUR_REF, an attempt to
fetch objects at the tip of them will be rejected, and because these
refs do not get advertised, "git push :" will not see local branches
that have the same name as them as "matching" ones to be sent.
An attempt to update/delete these hidden refs with an explicit
refspec, e.g. "git push origin :refs/hidden/22", is rejected. This
is not a new restriction. To the pusher, it would appear that there
is no such ref, so its push request will conclude with "Now that I
sent you all the data, it is time for you to update the refs. I saw
that the ref did not exist when I started pushing, and I want the
result to point at this commit". The receiving end will apply the
compare-and-swap rule to this request and rejects the push with
"Well, your update request conflicts with somebody else; I see there
is such a ref.", which is the right thing to do. Otherwise a push to
a hidden ref will always be "the last one wins", which is not a good
default.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-19 00:08:30 +00:00
|
|
|
continue;
|
2017-03-26 16:01:29 +00:00
|
|
|
if (is_null_oid(&cmd->new_oid))
|
upload/receive-pack: allow hiding ref hierarchies
A repository may have refs that are only used for its internal
bookkeeping purposes that should not be exposed to the others that
come over the network.
Teach upload-pack to omit some refs from its initial advertisement
by paying attention to the uploadpack.hiderefs multi-valued
configuration variable. Do the same to receive-pack via the
receive.hiderefs variable. As a convenient short-hand, allow using
transfer.hiderefs to set the value to both of these variables.
Any ref that is under the hierarchies listed on the value of these
variable is excluded from responses to requests made by "ls-remote",
"fetch", etc. (for upload-pack) and "push" (for receive-pack).
Because these hidden refs do not count as OUR_REF, an attempt to
fetch objects at the tip of them will be rejected, and because these
refs do not get advertised, "git push :" will not see local branches
that have the same name as them as "matching" ones to be sent.
An attempt to update/delete these hidden refs with an explicit
refspec, e.g. "git push origin :refs/hidden/22", is rejected. This
is not a new restriction. To the pusher, it would appear that there
is no such ref, so its push request will conclude with "Now that I
sent you all the data, it is time for you to update the refs. I saw
that the ref did not exist when I started pushing, and I want the
result to point at this commit". The receiving end will apply the
compare-and-swap rule to this request and rejects the push with
"Well, your update request conflicts with somebody else; I see there
is such a ref.", which is the right thing to do. Otherwise a push to
a hidden ref will always be "the last one wins", which is not a good
default.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-19 00:08:30 +00:00
|
|
|
cmd->error_string = "deny deleting a hidden ref";
|
|
|
|
else
|
|
|
|
cmd->error_string = "deny updating a hidden ref";
|
|
|
|
}
|
2015-11-03 07:58:16 +00:00
|
|
|
|
|
|
|
strbuf_release(&refname_full);
|
upload/receive-pack: allow hiding ref hierarchies
A repository may have refs that are only used for its internal
bookkeeping purposes that should not be exposed to the others that
come over the network.
Teach upload-pack to omit some refs from its initial advertisement
by paying attention to the uploadpack.hiderefs multi-valued
configuration variable. Do the same to receive-pack via the
receive.hiderefs variable. As a convenient short-hand, allow using
transfer.hiderefs to set the value to both of these variables.
Any ref that is under the hierarchies listed on the value of these
variable is excluded from responses to requests made by "ls-remote",
"fetch", etc. (for upload-pack) and "push" (for receive-pack).
Because these hidden refs do not count as OUR_REF, an attempt to
fetch objects at the tip of them will be rejected, and because these
refs do not get advertised, "git push :" will not see local branches
that have the same name as them as "matching" ones to be sent.
An attempt to update/delete these hidden refs with an explicit
refspec, e.g. "git push origin :refs/hidden/22", is rejected. This
is not a new restriction. To the pusher, it would appear that there
is no such ref, so its push request will conclude with "Now that I
sent you all the data, it is time for you to update the refs. I saw
that the ref did not exist when I started pushing, and I want the
result to point at this commit". The receiving end will apply the
compare-and-swap rule to this request and rejects the push with
"Well, your update request conflicts with somebody else; I see there
is such a ref.", which is the right thing to do. Otherwise a push to
a hidden ref will always be "the last one wins", which is not a good
default.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-19 00:08:30 +00:00
|
|
|
}
|
|
|
|
|
2015-01-08 03:23:15 +00:00
|
|
|
static int should_process_cmd(struct command *cmd)
|
|
|
|
{
|
|
|
|
return !cmd->error_string && !cmd->skip_update;
|
|
|
|
}
|
|
|
|
|
2022-06-02 12:25:36 +00:00
|
|
|
static void BUG_if_skipped_connectivity_check(struct command *commands,
|
2015-01-08 03:23:15 +00:00
|
|
|
struct shallow_info *si)
|
|
|
|
{
|
|
|
|
struct command *cmd;
|
|
|
|
|
|
|
|
for (cmd = commands; cmd; cmd = cmd->next) {
|
2022-06-02 12:25:36 +00:00
|
|
|
if (should_process_cmd(cmd) && si->shallow_ref[cmd->index])
|
|
|
|
bug("connectivity check has not been run on ref %s",
|
|
|
|
cmd->ref_name);
|
2015-01-08 03:23:15 +00:00
|
|
|
}
|
2022-06-02 12:25:36 +00:00
|
|
|
BUG_if_bug("connectivity check skipped???");
|
2015-01-08 03:23:15 +00:00
|
|
|
}
|
|
|
|
|
2015-01-08 03:23:17 +00:00
|
|
|
static void execute_commands_non_atomic(struct command *commands,
|
|
|
|
struct shallow_info *si)
|
|
|
|
{
|
|
|
|
struct command *cmd;
|
2015-01-08 03:23:18 +00:00
|
|
|
struct strbuf err = STRBUF_INIT;
|
|
|
|
|
2015-01-08 03:23:17 +00:00
|
|
|
for (cmd = commands; cmd; cmd = cmd->next) {
|
receive-pack: add new proc-receive hook
Git calls an internal `execute_commands` function to handle commands
sent from client to `git-receive-pack`. Regardless of what references
the user pushes, git creates or updates the corresponding references if
the user has write-permission. A contributor who has no
write-permission, cannot push to the repository directly. So, the
contributor has to write commits to an alternate location, and sends
pull request by emails or by other ways. We call this workflow as a
distributed workflow.
It would be more convenient to work in a centralized workflow like what
Gerrit provided for some cases. For example, a read-only user who
cannot push to a branch directly can run the following `git push`
command to push commits to a pseudo reference (has a prefix "refs/for/",
not "refs/heads/") to create a code review.
git push origin \
HEAD:refs/for/<branch-name>/<session>
The `<branch-name>` in the above example can be as simple as "master",
or a more complicated branch name like "foo/bar". The `<session>` in
the above example command can be the local branch name of the client
side, such as "my/topic".
We cannot implement a centralized workflow elegantly by using
"pre-receive" + "post-receive", because Git will call the internal
function "execute_commands" to create references (even the special
pseudo reference) between these two hooks. Even though we can delete
the temporarily created pseudo reference via the "post-receive" hook,
having a temporary reference is not safe for concurrent pushes.
So, add a filter and a new handler to support this kind of workflow.
The filter will check the prefix of the reference name, and if the
command has a special reference name, the filter will turn a specific
field (`run_proc_receive`) on for the command. Commands with this filed
turned on will be executed by a new handler (a hook named
"proc-receive") instead of the internal `execute_commands` function.
We can use this "proc-receive" command to create pull requests or send
emails for code review.
Suggested by Junio, this "proc-receive" hook reads the commands,
push-options (optional), and send result using a protocol in pkt-line
format. In the following example, the letter "S" stands for
"receive-pack" and letter "H" stands for the hook.
# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive result from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' to execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference. The alternate reference name
# and other status can be given in options
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt
After receiving a command, the hook will execute the command, and may
create/update different reference. For example, a command for a pseudo
reference "refs/for/master/topic" may create/update different reference
such as "refs/pull/123/head". The alternate reference name and other
status are given in option lines.
The list of commands returned from "proc-receive" will replace the
relevant commands that are sent from user to "receive-pack", and
"receive-pack" will continue to run the "execute_commands" function and
other routines. Finally, the result of the execution of these commands
will be reported to end user.
The reporting function from "receive-pack" to "send-pack" will be
extended in latter commit just like what the "proc-receive" hook reports
to "receive-pack".
Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27 15:45:44 +00:00
|
|
|
if (!should_process_cmd(cmd) || cmd->run_proc_receive)
|
2015-01-08 03:23:17 +00:00
|
|
|
continue;
|
|
|
|
|
2015-01-08 03:23:18 +00:00
|
|
|
transaction = ref_transaction_begin(&err);
|
|
|
|
if (!transaction) {
|
|
|
|
rp_error("%s", err.buf);
|
|
|
|
strbuf_reset(&err);
|
|
|
|
cmd->error_string = "transaction failed to start";
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2015-01-08 03:23:17 +00:00
|
|
|
cmd->error_string = update(cmd, si);
|
2015-01-08 03:23:18 +00:00
|
|
|
|
|
|
|
if (!cmd->error_string
|
|
|
|
&& ref_transaction_commit(transaction, &err)) {
|
|
|
|
rp_error("%s", err.buf);
|
|
|
|
strbuf_reset(&err);
|
|
|
|
cmd->error_string = "failed to update ref";
|
|
|
|
}
|
|
|
|
ref_transaction_free(transaction);
|
2015-01-08 03:23:17 +00:00
|
|
|
}
|
2015-01-08 03:23:19 +00:00
|
|
|
strbuf_release(&err);
|
|
|
|
}
|
2015-01-08 03:23:18 +00:00
|
|
|
|
2015-01-08 03:23:19 +00:00
|
|
|
static void execute_commands_atomic(struct command *commands,
|
|
|
|
struct shallow_info *si)
|
|
|
|
{
|
|
|
|
struct command *cmd;
|
|
|
|
struct strbuf err = STRBUF_INIT;
|
|
|
|
const char *reported_error = "atomic push failure";
|
|
|
|
|
|
|
|
transaction = ref_transaction_begin(&err);
|
|
|
|
if (!transaction) {
|
|
|
|
rp_error("%s", err.buf);
|
|
|
|
strbuf_reset(&err);
|
|
|
|
reported_error = "transaction failed to start";
|
|
|
|
goto failure;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (cmd = commands; cmd; cmd = cmd->next) {
|
receive-pack: add new proc-receive hook
Git calls an internal `execute_commands` function to handle commands
sent from client to `git-receive-pack`. Regardless of what references
the user pushes, git creates or updates the corresponding references if
the user has write-permission. A contributor who has no
write-permission, cannot push to the repository directly. So, the
contributor has to write commits to an alternate location, and sends
pull request by emails or by other ways. We call this workflow as a
distributed workflow.
It would be more convenient to work in a centralized workflow like what
Gerrit provided for some cases. For example, a read-only user who
cannot push to a branch directly can run the following `git push`
command to push commits to a pseudo reference (has a prefix "refs/for/",
not "refs/heads/") to create a code review.
git push origin \
HEAD:refs/for/<branch-name>/<session>
The `<branch-name>` in the above example can be as simple as "master",
or a more complicated branch name like "foo/bar". The `<session>` in
the above example command can be the local branch name of the client
side, such as "my/topic".
We cannot implement a centralized workflow elegantly by using
"pre-receive" + "post-receive", because Git will call the internal
function "execute_commands" to create references (even the special
pseudo reference) between these two hooks. Even though we can delete
the temporarily created pseudo reference via the "post-receive" hook,
having a temporary reference is not safe for concurrent pushes.
So, add a filter and a new handler to support this kind of workflow.
The filter will check the prefix of the reference name, and if the
command has a special reference name, the filter will turn a specific
field (`run_proc_receive`) on for the command. Commands with this filed
turned on will be executed by a new handler (a hook named
"proc-receive") instead of the internal `execute_commands` function.
We can use this "proc-receive" command to create pull requests or send
emails for code review.
Suggested by Junio, this "proc-receive" hook reads the commands,
push-options (optional), and send result using a protocol in pkt-line
format. In the following example, the letter "S" stands for
"receive-pack" and letter "H" stands for the hook.
# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive result from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' to execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference. The alternate reference name
# and other status can be given in options
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt
After receiving a command, the hook will execute the command, and may
create/update different reference. For example, a command for a pseudo
reference "refs/for/master/topic" may create/update different reference
such as "refs/pull/123/head". The alternate reference name and other
status are given in option lines.
The list of commands returned from "proc-receive" will replace the
relevant commands that are sent from user to "receive-pack", and
"receive-pack" will continue to run the "execute_commands" function and
other routines. Finally, the result of the execution of these commands
will be reported to end user.
The reporting function from "receive-pack" to "send-pack" will be
extended in latter commit just like what the "proc-receive" hook reports
to "receive-pack".
Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27 15:45:44 +00:00
|
|
|
if (!should_process_cmd(cmd) || cmd->run_proc_receive)
|
2015-01-08 03:23:19 +00:00
|
|
|
continue;
|
|
|
|
|
|
|
|
cmd->error_string = update(cmd, si);
|
|
|
|
|
|
|
|
if (cmd->error_string)
|
|
|
|
goto failure;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ref_transaction_commit(transaction, &err)) {
|
|
|
|
rp_error("%s", err.buf);
|
|
|
|
reported_error = "atomic transaction failed";
|
|
|
|
goto failure;
|
|
|
|
}
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
failure:
|
|
|
|
for (cmd = commands; cmd; cmd = cmd->next)
|
|
|
|
if (!cmd->error_string)
|
|
|
|
cmd->error_string = reported_error;
|
|
|
|
|
|
|
|
cleanup:
|
|
|
|
ref_transaction_free(transaction);
|
2015-01-08 03:23:18 +00:00
|
|
|
strbuf_release(&err);
|
2015-01-08 03:23:17 +00:00
|
|
|
}
|
|
|
|
|
2013-12-05 13:02:47 +00:00
|
|
|
static void execute_commands(struct command *commands,
|
|
|
|
const char *unpacker_error,
|
push options: {pre,post}-receive hook learns about push options
The environment variable GIT_PUSH_OPTION_COUNT is set to the number of
push options sent, and GIT_PUSH_OPTION_{0,1,..} is set to the transmitted
option.
The code is not executed as the push options are set to NULL, nor is the
new capability advertised.
There was some discussion back and forth how to present these push options
to the user as there are some ways to do it:
Keep all options in one environment variable
============================================
+ easiest way to implement in Git
- This would make things hard to parse correctly in the hook.
Put the options in files instead,
filenames are in GIT_PUSH_OPTION_FILES
======================================
+ After a discussion about environment variables and shells, we may not
want to put user data into an environment variable (see [1] for example).
+ We could transmit binaries, i.e. we're not bound to C strings as
we are when using environment variables to the user.
+ Maybe easier to parse than constructing environment variable names
GIT_PUSH_OPTION_{0,1,..} yourself
- cleanup of the temporary files is hard to do reliably
- we have race conditions with multiple clients pushing, hence we'd need
to use mkstemp. That's not too bad, but still.
Use environment variables, but restrict to key/value pairs
==========================================================
(When the user pushes a push option `foo=bar`, we'd
GIT_PUSH_OPTION_foo=bar)
+ very easy to parse for a simple model of push options
- it's not sufficient for more elaborate models, e.g.
it doesn't allow doubles (e.g. cc=reviewer@email)
Present the options in different environment variables
======================================================
(This is implemented)
* harder to parse as a user, but we have a sample hook for that.
- doesn't allow binary files
+ allows the same option twice, i.e. is not restrictive about
options, except for binary files.
+ doesn't clutter a remote directory with (possibly stale)
temporary files
As we first want to focus on getting simple strings to work
reliably, we go with the last option for now. If we want to
do transmission of binaries later, we can just attach a
'side-channel', e.g. "any push option that contains a '\0' is
put into a file instead of the environment variable and we'd
have new GIT_PUSH_OPTION_FILES, GIT_PUSH_OPTION_FILENAME_{0,1,..}
environment variables".
[1] 'Shellshock' https://lwn.net/Articles/614218/
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-14 21:49:45 +00:00
|
|
|
struct shallow_info *si,
|
|
|
|
const struct string_list *push_options)
|
2005-06-30 00:52:11 +00:00
|
|
|
{
|
2016-07-15 10:36:14 +00:00
|
|
|
struct check_connected_options opt = CHECK_CONNECTED_INIT;
|
2010-04-19 22:08:30 +00:00
|
|
|
struct command *cmd;
|
2013-12-05 13:02:47 +00:00
|
|
|
struct iterate_data data;
|
2016-07-15 10:36:14 +00:00
|
|
|
struct async muxer;
|
|
|
|
int err_fd = 0;
|
receive-pack: add new proc-receive hook
Git calls an internal `execute_commands` function to handle commands
sent from client to `git-receive-pack`. Regardless of what references
the user pushes, git creates or updates the corresponding references if
the user has write-permission. A contributor who has no
write-permission, cannot push to the repository directly. So, the
contributor has to write commits to an alternate location, and sends
pull request by emails or by other ways. We call this workflow as a
distributed workflow.
It would be more convenient to work in a centralized workflow like what
Gerrit provided for some cases. For example, a read-only user who
cannot push to a branch directly can run the following `git push`
command to push commits to a pseudo reference (has a prefix "refs/for/",
not "refs/heads/") to create a code review.
git push origin \
HEAD:refs/for/<branch-name>/<session>
The `<branch-name>` in the above example can be as simple as "master",
or a more complicated branch name like "foo/bar". The `<session>` in
the above example command can be the local branch name of the client
side, such as "my/topic".
We cannot implement a centralized workflow elegantly by using
"pre-receive" + "post-receive", because Git will call the internal
function "execute_commands" to create references (even the special
pseudo reference) between these two hooks. Even though we can delete
the temporarily created pseudo reference via the "post-receive" hook,
having a temporary reference is not safe for concurrent pushes.
So, add a filter and a new handler to support this kind of workflow.
The filter will check the prefix of the reference name, and if the
command has a special reference name, the filter will turn a specific
field (`run_proc_receive`) on for the command. Commands with this filed
turned on will be executed by a new handler (a hook named
"proc-receive") instead of the internal `execute_commands` function.
We can use this "proc-receive" command to create pull requests or send
emails for code review.
Suggested by Junio, this "proc-receive" hook reads the commands,
push-options (optional), and send result using a protocol in pkt-line
format. In the following example, the letter "S" stands for
"receive-pack" and letter "H" stands for the hook.
# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive result from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' to execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference. The alternate reference name
# and other status can be given in options
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt
After receiving a command, the hook will execute the command, and may
create/update different reference. For example, a command for a pseudo
reference "refs/for/master/topic" may create/update different reference
such as "refs/pull/123/head". The alternate reference name and other
status are given in option lines.
The list of commands returned from "proc-receive" will replace the
relevant commands that are sent from user to "receive-pack", and
"receive-pack" will continue to run the "execute_commands" function and
other routines. Finally, the result of the execution of these commands
will be reported to end user.
The reporting function from "receive-pack" to "send-pack" will be
extended in latter commit just like what the "proc-receive" hook reports
to "receive-pack".
Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27 15:45:44 +00:00
|
|
|
int run_proc_receive = 0;
|
2007-03-07 21:51:59 +00:00
|
|
|
|
|
|
|
if (unpacker_error) {
|
2010-04-19 22:08:30 +00:00
|
|
|
for (cmd = commands; cmd; cmd = cmd->next)
|
2012-09-21 05:38:46 +00:00
|
|
|
cmd->error_string = "unpacker error";
|
2007-03-07 21:51:59 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-07-15 10:36:14 +00:00
|
|
|
if (use_sideband) {
|
|
|
|
memset(&muxer, 0, sizeof(muxer));
|
|
|
|
muxer.proc = copy_to_sideband;
|
|
|
|
muxer.in = -1;
|
|
|
|
if (!start_async(&muxer))
|
|
|
|
err_fd = muxer.in;
|
|
|
|
/* ...else, continue without relaying sideband */
|
|
|
|
}
|
|
|
|
|
2013-12-05 13:02:47 +00:00
|
|
|
data.cmds = commands;
|
|
|
|
data.si = si;
|
2016-07-15 10:36:14 +00:00
|
|
|
opt.err_fd = err_fd;
|
2016-07-15 10:36:35 +00:00
|
|
|
opt.progress = err_fd && !quiet;
|
2016-10-03 20:49:14 +00:00
|
|
|
opt.env = tmp_objdir_env(tmp_objdir);
|
receive-pack: only use visible refs for connectivity check
When serving a push, git-receive-pack(1) needs to verify that the
packfile sent by the client contains all objects that are required by
the updated references. This connectivity check works by marking all
preexisting references as uninteresting and using the new reference tips
as starting point for a graph walk.
Marking all preexisting references as uninteresting can be a problem
when it comes to performance. Git forges tend to do internal bookkeeping
to keep alive sets of objects for internal use or make them easy to find
via certain references. These references are typically hidden away from
the user so that they are neither advertised nor writeable. At GitLab,
we have one particular repository that contains a total of 7 million
references, of which 6.8 million are indeed internal references. With
the current connectivity check we are forced to load all these
references in order to mark them as uninteresting, and this alone takes
around 15 seconds to compute.
We can optimize this by only taking into account the set of visible refs
when marking objects as uninteresting. This means that we may now walk
more objects until we hit any object that is marked as uninteresting.
But it is rather unlikely that clients send objects that make large
parts of objects reachable that have previously only ever been hidden,
whereas the common case is to push incremental changes that build on top
of the visible object graph.
This provides a huge boost to performance in the mentioned repository,
where the vast majority of its refs hidden. Pushing a new commit into
this repo with `transfer.hideRefs` set up to hide 6.8 million of 7 refs
as it is configured in Gitaly leads to a 4.5-fold speedup:
Benchmark 1: main
Time (mean ± σ): 30.977 s ± 0.157 s [User: 30.226 s, System: 1.083 s]
Range (min … max): 30.796 s … 31.071 s 3 runs
Benchmark 2: pks-connectivity-check-hide-refs
Time (mean ± σ): 6.799 s ± 0.063 s [User: 6.803 s, System: 0.354 s]
Range (min … max): 6.729 s … 6.850 s 3 runs
Summary
'pks-connectivity-check-hide-refs' ran
4.56 ± 0.05 times faster than 'main'
As we mostly go through the same codepaths even in the case where there
are no hidden refs at all compared to the code before there is no change
in performance when no refs are hidden:
Benchmark 1: main
Time (mean ± σ): 48.188 s ± 0.432 s [User: 49.326 s, System: 5.009 s]
Range (min … max): 47.706 s … 48.539 s 3 runs
Benchmark 2: pks-connectivity-check-hide-refs
Time (mean ± σ): 48.027 s ± 0.500 s [User: 48.934 s, System: 5.025 s]
Range (min … max): 47.504 s … 48.500 s 3 runs
Summary
'pks-connectivity-check-hide-refs' ran
1.00 ± 0.01 times faster than 'main'
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-11-17 05:47:04 +00:00
|
|
|
opt.exclude_hidden_refs_section = "receive";
|
|
|
|
|
2016-07-15 10:36:14 +00:00
|
|
|
if (check_connected(iterate_receive_command_list, &data, &opt))
|
2013-12-05 13:02:47 +00:00
|
|
|
set_connectivity_errors(commands, si);
|
2011-09-02 23:52:08 +00:00
|
|
|
|
2016-07-15 10:36:14 +00:00
|
|
|
if (use_sideband)
|
|
|
|
finish_async(&muxer);
|
|
|
|
|
upload/receive-pack: allow hiding ref hierarchies
A repository may have refs that are only used for its internal
bookkeeping purposes that should not be exposed to the others that
come over the network.
Teach upload-pack to omit some refs from its initial advertisement
by paying attention to the uploadpack.hiderefs multi-valued
configuration variable. Do the same to receive-pack via the
receive.hiderefs variable. As a convenient short-hand, allow using
transfer.hiderefs to set the value to both of these variables.
Any ref that is under the hierarchies listed on the value of these
variable is excluded from responses to requests made by "ls-remote",
"fetch", etc. (for upload-pack) and "push" (for receive-pack).
Because these hidden refs do not count as OUR_REF, an attempt to
fetch objects at the tip of them will be rejected, and because these
refs do not get advertised, "git push :" will not see local branches
that have the same name as them as "matching" ones to be sent.
An attempt to update/delete these hidden refs with an explicit
refspec, e.g. "git push origin :refs/hidden/22", is rejected. This
is not a new restriction. To the pusher, it would appear that there
is no such ref, so its push request will conclude with "Now that I
sent you all the data, it is time for you to update the refs. I saw
that the ref did not exist when I started pushing, and I want the
result to point at this commit". The receiving end will apply the
compare-and-swap rule to this request and rejects the push with
"Well, your update request conflicts with somebody else; I see there
is such a ref.", which is the right thing to do. Otherwise a push to
a hidden ref will always be "the last one wins", which is not a good
default.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-19 00:08:30 +00:00
|
|
|
reject_updates_to_hidden(commands);
|
|
|
|
|
receive-pack: add new proc-receive hook
Git calls an internal `execute_commands` function to handle commands
sent from client to `git-receive-pack`. Regardless of what references
the user pushes, git creates or updates the corresponding references if
the user has write-permission. A contributor who has no
write-permission, cannot push to the repository directly. So, the
contributor has to write commits to an alternate location, and sends
pull request by emails or by other ways. We call this workflow as a
distributed workflow.
It would be more convenient to work in a centralized workflow like what
Gerrit provided for some cases. For example, a read-only user who
cannot push to a branch directly can run the following `git push`
command to push commits to a pseudo reference (has a prefix "refs/for/",
not "refs/heads/") to create a code review.
git push origin \
HEAD:refs/for/<branch-name>/<session>
The `<branch-name>` in the above example can be as simple as "master",
or a more complicated branch name like "foo/bar". The `<session>` in
the above example command can be the local branch name of the client
side, such as "my/topic".
We cannot implement a centralized workflow elegantly by using
"pre-receive" + "post-receive", because Git will call the internal
function "execute_commands" to create references (even the special
pseudo reference) between these two hooks. Even though we can delete
the temporarily created pseudo reference via the "post-receive" hook,
having a temporary reference is not safe for concurrent pushes.
So, add a filter and a new handler to support this kind of workflow.
The filter will check the prefix of the reference name, and if the
command has a special reference name, the filter will turn a specific
field (`run_proc_receive`) on for the command. Commands with this filed
turned on will be executed by a new handler (a hook named
"proc-receive") instead of the internal `execute_commands` function.
We can use this "proc-receive" command to create pull requests or send
emails for code review.
Suggested by Junio, this "proc-receive" hook reads the commands,
push-options (optional), and send result using a protocol in pkt-line
format. In the following example, the letter "S" stands for
"receive-pack" and letter "H" stands for the hook.
# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive result from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' to execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference. The alternate reference name
# and other status can be given in options
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt
After receiving a command, the hook will execute the command, and may
create/update different reference. For example, a command for a pseudo
reference "refs/for/master/topic" may create/update different reference
such as "refs/pull/123/head". The alternate reference name and other
status are given in option lines.
The list of commands returned from "proc-receive" will replace the
relevant commands that are sent from user to "receive-pack", and
"receive-pack" will continue to run the "execute_commands" function and
other routines. Finally, the result of the execution of these commands
will be reported to end user.
The reporting function from "receive-pack" to "send-pack" will be
extended in latter commit just like what the "proc-receive" hook reports
to "receive-pack".
Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27 15:45:44 +00:00
|
|
|
/*
|
|
|
|
* Try to find commands that have special prefix in their reference names,
|
|
|
|
* and mark them to run an external "proc-receive" hook later.
|
|
|
|
*/
|
2020-08-27 15:45:48 +00:00
|
|
|
if (proc_receive_ref) {
|
|
|
|
for (cmd = commands; cmd; cmd = cmd->next) {
|
|
|
|
if (!should_process_cmd(cmd))
|
|
|
|
continue;
|
receive-pack: add new proc-receive hook
Git calls an internal `execute_commands` function to handle commands
sent from client to `git-receive-pack`. Regardless of what references
the user pushes, git creates or updates the corresponding references if
the user has write-permission. A contributor who has no
write-permission, cannot push to the repository directly. So, the
contributor has to write commits to an alternate location, and sends
pull request by emails or by other ways. We call this workflow as a
distributed workflow.
It would be more convenient to work in a centralized workflow like what
Gerrit provided for some cases. For example, a read-only user who
cannot push to a branch directly can run the following `git push`
command to push commits to a pseudo reference (has a prefix "refs/for/",
not "refs/heads/") to create a code review.
git push origin \
HEAD:refs/for/<branch-name>/<session>
The `<branch-name>` in the above example can be as simple as "master",
or a more complicated branch name like "foo/bar". The `<session>` in
the above example command can be the local branch name of the client
side, such as "my/topic".
We cannot implement a centralized workflow elegantly by using
"pre-receive" + "post-receive", because Git will call the internal
function "execute_commands" to create references (even the special
pseudo reference) between these two hooks. Even though we can delete
the temporarily created pseudo reference via the "post-receive" hook,
having a temporary reference is not safe for concurrent pushes.
So, add a filter and a new handler to support this kind of workflow.
The filter will check the prefix of the reference name, and if the
command has a special reference name, the filter will turn a specific
field (`run_proc_receive`) on for the command. Commands with this filed
turned on will be executed by a new handler (a hook named
"proc-receive") instead of the internal `execute_commands` function.
We can use this "proc-receive" command to create pull requests or send
emails for code review.
Suggested by Junio, this "proc-receive" hook reads the commands,
push-options (optional), and send result using a protocol in pkt-line
format. In the following example, the letter "S" stands for
"receive-pack" and letter "H" stands for the hook.
# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive result from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' to execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference. The alternate reference name
# and other status can be given in options
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt
After receiving a command, the hook will execute the command, and may
create/update different reference. For example, a command for a pseudo
reference "refs/for/master/topic" may create/update different reference
such as "refs/pull/123/head". The alternate reference name and other
status are given in option lines.
The list of commands returned from "proc-receive" will replace the
relevant commands that are sent from user to "receive-pack", and
"receive-pack" will continue to run the "execute_commands" function and
other routines. Finally, the result of the execution of these commands
will be reported to end user.
The reporting function from "receive-pack" to "send-pack" will be
extended in latter commit just like what the "proc-receive" hook reports
to "receive-pack".
Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27 15:45:44 +00:00
|
|
|
|
2020-08-27 15:45:48 +00:00
|
|
|
if (proc_receive_ref_matches(cmd)) {
|
|
|
|
cmd->run_proc_receive = RUN_PROC_RECEIVE_SCHEDULED;
|
|
|
|
run_proc_receive = 1;
|
|
|
|
}
|
receive-pack: add new proc-receive hook
Git calls an internal `execute_commands` function to handle commands
sent from client to `git-receive-pack`. Regardless of what references
the user pushes, git creates or updates the corresponding references if
the user has write-permission. A contributor who has no
write-permission, cannot push to the repository directly. So, the
contributor has to write commits to an alternate location, and sends
pull request by emails or by other ways. We call this workflow as a
distributed workflow.
It would be more convenient to work in a centralized workflow like what
Gerrit provided for some cases. For example, a read-only user who
cannot push to a branch directly can run the following `git push`
command to push commits to a pseudo reference (has a prefix "refs/for/",
not "refs/heads/") to create a code review.
git push origin \
HEAD:refs/for/<branch-name>/<session>
The `<branch-name>` in the above example can be as simple as "master",
or a more complicated branch name like "foo/bar". The `<session>` in
the above example command can be the local branch name of the client
side, such as "my/topic".
We cannot implement a centralized workflow elegantly by using
"pre-receive" + "post-receive", because Git will call the internal
function "execute_commands" to create references (even the special
pseudo reference) between these two hooks. Even though we can delete
the temporarily created pseudo reference via the "post-receive" hook,
having a temporary reference is not safe for concurrent pushes.
So, add a filter and a new handler to support this kind of workflow.
The filter will check the prefix of the reference name, and if the
command has a special reference name, the filter will turn a specific
field (`run_proc_receive`) on for the command. Commands with this filed
turned on will be executed by a new handler (a hook named
"proc-receive") instead of the internal `execute_commands` function.
We can use this "proc-receive" command to create pull requests or send
emails for code review.
Suggested by Junio, this "proc-receive" hook reads the commands,
push-options (optional), and send result using a protocol in pkt-line
format. In the following example, the letter "S" stands for
"receive-pack" and letter "H" stands for the hook.
# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive result from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' to execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference. The alternate reference name
# and other status can be given in options
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt
After receiving a command, the hook will execute the command, and may
create/update different reference. For example, a command for a pseudo
reference "refs/for/master/topic" may create/update different reference
such as "refs/pull/123/head". The alternate reference name and other
status are given in option lines.
The list of commands returned from "proc-receive" will replace the
relevant commands that are sent from user to "receive-pack", and
"receive-pack" will continue to run the "execute_commands" function and
other routines. Finally, the result of the execution of these commands
will be reported to end user.
The reporting function from "receive-pack" to "send-pack" will be
extended in latter commit just like what the "proc-receive" hook reports
to "receive-pack".
Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27 15:45:44 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
push options: {pre,post}-receive hook learns about push options
The environment variable GIT_PUSH_OPTION_COUNT is set to the number of
push options sent, and GIT_PUSH_OPTION_{0,1,..} is set to the transmitted
option.
The code is not executed as the push options are set to NULL, nor is the
new capability advertised.
There was some discussion back and forth how to present these push options
to the user as there are some ways to do it:
Keep all options in one environment variable
============================================
+ easiest way to implement in Git
- This would make things hard to parse correctly in the hook.
Put the options in files instead,
filenames are in GIT_PUSH_OPTION_FILES
======================================
+ After a discussion about environment variables and shells, we may not
want to put user data into an environment variable (see [1] for example).
+ We could transmit binaries, i.e. we're not bound to C strings as
we are when using environment variables to the user.
+ Maybe easier to parse than constructing environment variable names
GIT_PUSH_OPTION_{0,1,..} yourself
- cleanup of the temporary files is hard to do reliably
- we have race conditions with multiple clients pushing, hence we'd need
to use mkstemp. That's not too bad, but still.
Use environment variables, but restrict to key/value pairs
==========================================================
(When the user pushes a push option `foo=bar`, we'd
GIT_PUSH_OPTION_foo=bar)
+ very easy to parse for a simple model of push options
- it's not sufficient for more elaborate models, e.g.
it doesn't allow doubles (e.g. cc=reviewer@email)
Present the options in different environment variables
======================================================
(This is implemented)
* harder to parse as a user, but we have a sample hook for that.
- doesn't allow binary files
+ allows the same option twice, i.e. is not restrictive about
options, except for binary files.
+ doesn't clutter a remote directory with (possibly stale)
temporary files
As we first want to focus on getting simple strings to work
reliably, we go with the last option for now. If we want to
do transmission of binaries later, we can just attach a
'side-channel', e.g. "any push option that contains a '\0' is
put into a file instead of the environment variable and we'd
have new GIT_PUSH_OPTION_FILES, GIT_PUSH_OPTION_FILENAME_{0,1,..}
environment variables".
[1] 'Shellshock' https://lwn.net/Articles/614218/
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-14 21:49:45 +00:00
|
|
|
if (run_receive_hook(commands, "pre-receive", 0, push_options)) {
|
2012-02-13 20:17:12 +00:00
|
|
|
for (cmd = commands; cmd; cmd = cmd->next) {
|
|
|
|
if (!cmd->error_string)
|
|
|
|
cmd->error_string = "pre-receive hook declined";
|
|
|
|
}
|
2007-03-07 21:52:05 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2022-01-29 06:35:38 +00:00
|
|
|
/*
|
|
|
|
* If there is no command ready to run, should return directly to destroy
|
|
|
|
* temporary data in the quarantine area.
|
|
|
|
*/
|
|
|
|
for (cmd = commands; cmd && cmd->error_string; cmd = cmd->next)
|
|
|
|
; /* nothing */
|
|
|
|
if (!cmd)
|
|
|
|
return;
|
|
|
|
|
2016-10-03 20:49:14 +00:00
|
|
|
/*
|
|
|
|
* Now we'll start writing out refs, which means the objects need
|
|
|
|
* to be in their final positions so that other processes can see them.
|
|
|
|
*/
|
|
|
|
if (tmp_objdir_migrate(tmp_objdir) < 0) {
|
|
|
|
for (cmd = commands; cmd; cmd = cmd->next) {
|
|
|
|
if (!cmd->error_string)
|
|
|
|
cmd->error_string = "unable to migrate objects to permanent storage";
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
tmp_objdir = NULL;
|
|
|
|
|
2010-04-19 22:19:18 +00:00
|
|
|
check_aliased_updates(commands);
|
|
|
|
|
2011-12-13 14:17:48 +00:00
|
|
|
free(head_name_to_free);
|
2017-10-01 07:29:03 +00:00
|
|
|
head_name = head_name_to_free = resolve_refdup("HEAD", 0, NULL, NULL);
|
2009-02-09 06:31:21 +00:00
|
|
|
|
receive-pack: add new proc-receive hook
Git calls an internal `execute_commands` function to handle commands
sent from client to `git-receive-pack`. Regardless of what references
the user pushes, git creates or updates the corresponding references if
the user has write-permission. A contributor who has no
write-permission, cannot push to the repository directly. So, the
contributor has to write commits to an alternate location, and sends
pull request by emails or by other ways. We call this workflow as a
distributed workflow.
It would be more convenient to work in a centralized workflow like what
Gerrit provided for some cases. For example, a read-only user who
cannot push to a branch directly can run the following `git push`
command to push commits to a pseudo reference (has a prefix "refs/for/",
not "refs/heads/") to create a code review.
git push origin \
HEAD:refs/for/<branch-name>/<session>
The `<branch-name>` in the above example can be as simple as "master",
or a more complicated branch name like "foo/bar". The `<session>` in
the above example command can be the local branch name of the client
side, such as "my/topic".
We cannot implement a centralized workflow elegantly by using
"pre-receive" + "post-receive", because Git will call the internal
function "execute_commands" to create references (even the special
pseudo reference) between these two hooks. Even though we can delete
the temporarily created pseudo reference via the "post-receive" hook,
having a temporary reference is not safe for concurrent pushes.
So, add a filter and a new handler to support this kind of workflow.
The filter will check the prefix of the reference name, and if the
command has a special reference name, the filter will turn a specific
field (`run_proc_receive`) on for the command. Commands with this filed
turned on will be executed by a new handler (a hook named
"proc-receive") instead of the internal `execute_commands` function.
We can use this "proc-receive" command to create pull requests or send
emails for code review.
Suggested by Junio, this "proc-receive" hook reads the commands,
push-options (optional), and send result using a protocol in pkt-line
format. In the following example, the letter "S" stands for
"receive-pack" and letter "H" stands for the hook.
# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive result from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' to execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference. The alternate reference name
# and other status can be given in options
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt
After receiving a command, the hook will execute the command, and may
create/update different reference. For example, a command for a pseudo
reference "refs/for/master/topic" may create/update different reference
such as "refs/pull/123/head". The alternate reference name and other
status are given in option lines.
The list of commands returned from "proc-receive" will replace the
relevant commands that are sent from user to "receive-pack", and
"receive-pack" will continue to run the "execute_commands" function and
other routines. Finally, the result of the execution of these commands
will be reported to end user.
The reporting function from "receive-pack" to "send-pack" will be
extended in latter commit just like what the "proc-receive" hook reports
to "receive-pack".
Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-27 15:45:44 +00:00
|
|
|
if (run_proc_receive &&
|
|
|
|
run_proc_receive_hook(commands, push_options))
|
|
|
|
for (cmd = commands; cmd; cmd = cmd->next)
|
|
|
|
if (!cmd->error_string &&
|
|
|
|
!(cmd->run_proc_receive & RUN_PROC_RECEIVE_RETURNED) &&
|
|
|
|
(cmd->run_proc_receive || use_atomic))
|
|
|
|
cmd->error_string = "fail to run proc-receive hook";
|
|
|
|
|
2015-01-08 03:23:19 +00:00
|
|
|
if (use_atomic)
|
|
|
|
execute_commands_atomic(commands, si);
|
|
|
|
else
|
|
|
|
execute_commands_non_atomic(commands, si);
|
2013-12-05 13:02:47 +00:00
|
|
|
|
2015-01-08 03:23:15 +00:00
|
|
|
if (shallow_update)
|
2022-06-02 12:25:36 +00:00
|
|
|
BUG_if_skipped_connectivity_check(commands, si);
|
2005-06-30 00:52:11 +00:00
|
|
|
}
|
|
|
|
|
2014-08-15 21:28:28 +00:00
|
|
|
static struct command **queue_command(struct command **tail,
|
|
|
|
const char *line,
|
|
|
|
int linelen)
|
|
|
|
{
|
2017-03-26 16:01:29 +00:00
|
|
|
struct object_id old_oid, new_oid;
|
2014-08-15 21:28:28 +00:00
|
|
|
struct command *cmd;
|
|
|
|
const char *refname;
|
|
|
|
int reflen;
|
2017-03-26 16:01:29 +00:00
|
|
|
const char *p;
|
2014-08-15 21:28:28 +00:00
|
|
|
|
2017-03-26 16:01:29 +00:00
|
|
|
if (parse_oid_hex(line, &old_oid, &p) ||
|
|
|
|
*p++ != ' ' ||
|
|
|
|
parse_oid_hex(p, &new_oid, &p) ||
|
|
|
|
*p++ != ' ')
|
2014-08-15 21:28:28 +00:00
|
|
|
die("protocol error: expected old/new/ref, got '%s'", line);
|
|
|
|
|
2017-03-26 16:01:29 +00:00
|
|
|
refname = p;
|
|
|
|
reflen = linelen - (p - line);
|
2016-08-13 15:38:56 +00:00
|
|
|
FLEX_ALLOC_MEM(cmd, ref_name, refname, reflen);
|
2017-03-26 16:01:29 +00:00
|
|
|
oidcpy(&cmd->old_oid, &old_oid);
|
|
|
|
oidcpy(&cmd->new_oid, &new_oid);
|
2014-08-15 21:28:28 +00:00
|
|
|
*tail = cmd;
|
|
|
|
return &cmd->next;
|
|
|
|
}
|
|
|
|
|
2023-02-06 23:07:52 +00:00
|
|
|
static void free_commands(struct command *commands)
|
|
|
|
{
|
|
|
|
while (commands) {
|
|
|
|
struct command *next = commands->next;
|
|
|
|
|
|
|
|
free(commands);
|
|
|
|
commands = next;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-08-18 21:38:45 +00:00
|
|
|
static void queue_commands_from_cert(struct command **tail,
|
|
|
|
struct strbuf *push_cert)
|
|
|
|
{
|
|
|
|
const char *boc, *eoc;
|
|
|
|
|
|
|
|
if (*tail)
|
|
|
|
die("protocol error: got both push certificate and unsigned commands");
|
|
|
|
|
|
|
|
boc = strstr(push_cert->buf, "\n\n");
|
|
|
|
if (!boc)
|
|
|
|
die("malformed push certificate %.*s", 100, push_cert->buf);
|
|
|
|
else
|
|
|
|
boc += 2;
|
2021-02-11 02:08:03 +00:00
|
|
|
eoc = push_cert->buf + parse_signed_buffer(push_cert->buf, push_cert->len);
|
2014-08-18 21:38:45 +00:00
|
|
|
|
|
|
|
while (boc < eoc) {
|
|
|
|
const char *eol = memchr(boc, '\n', eoc - boc);
|
2017-03-26 16:01:28 +00:00
|
|
|
tail = queue_command(tail, boc, eol ? eol - boc : eoc - boc);
|
2014-08-18 21:38:45 +00:00
|
|
|
boc = eol ? eol + 1 : eoc;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-12-29 21:19:14 +00:00
|
|
|
static struct command *read_head_info(struct packet_reader *reader,
|
|
|
|
struct oid_array *shallow)
|
2005-06-30 00:52:11 +00:00
|
|
|
{
|
2010-04-19 22:08:30 +00:00
|
|
|
struct command *commands = NULL;
|
2005-06-30 06:01:14 +00:00
|
|
|
struct command **p = &commands;
|
2005-06-30 00:52:11 +00:00
|
|
|
for (;;) {
|
2018-12-29 21:19:14 +00:00
|
|
|
int linelen;
|
2005-06-30 06:01:14 +00:00
|
|
|
|
2018-12-29 21:19:14 +00:00
|
|
|
if (packet_reader_read(reader) != PACKET_READ_NORMAL)
|
2005-06-30 00:52:11 +00:00
|
|
|
break;
|
2013-12-05 13:02:44 +00:00
|
|
|
|
2018-12-29 21:19:14 +00:00
|
|
|
if (reader->pktlen > 8 && starts_with(reader->line, "shallow ")) {
|
2017-03-26 16:01:29 +00:00
|
|
|
struct object_id oid;
|
2018-12-29 21:19:14 +00:00
|
|
|
if (get_oid_hex(reader->line + 8, &oid))
|
2014-08-15 21:26:17 +00:00
|
|
|
die("protocol error: expected shallow sha, got '%s'",
|
2018-12-29 21:19:14 +00:00
|
|
|
reader->line + 8);
|
2017-03-31 01:40:00 +00:00
|
|
|
oid_array_append(shallow, &oid);
|
2013-12-05 13:02:44 +00:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2018-12-29 21:19:14 +00:00
|
|
|
linelen = strlen(reader->line);
|
|
|
|
if (linelen < reader->pktlen) {
|
|
|
|
const char *feature_list = reader->line + linelen + 1;
|
2020-05-25 19:59:01 +00:00
|
|
|
const char *hash = NULL;
|
2020-11-11 23:29:34 +00:00
|
|
|
const char *client_sid;
|
2023-04-14 21:25:20 +00:00
|
|
|
size_t len = 0;
|
2012-01-08 21:06:19 +00:00
|
|
|
if (parse_feature_request(feature_list, "report-status"))
|
2005-12-26 07:18:37 +00:00
|
|
|
report_status = 1;
|
2020-08-27 15:45:46 +00:00
|
|
|
if (parse_feature_request(feature_list, "report-status-v2"))
|
|
|
|
report_status_v2 = 1;
|
2012-01-08 21:06:19 +00:00
|
|
|
if (parse_feature_request(feature_list, "side-band-64k"))
|
2010-02-05 20:57:41 +00:00
|
|
|
use_sideband = LARGE_PACKET_MAX;
|
2012-01-08 21:06:20 +00:00
|
|
|
if (parse_feature_request(feature_list, "quiet"))
|
|
|
|
quiet = 1;
|
2015-01-08 03:23:20 +00:00
|
|
|
if (advertise_atomic_push
|
|
|
|
&& parse_feature_request(feature_list, "atomic"))
|
|
|
|
use_atomic = 1;
|
2016-07-14 21:49:46 +00:00
|
|
|
if (advertise_push_options
|
|
|
|
&& parse_feature_request(feature_list, "push-options"))
|
|
|
|
use_push_options = 1;
|
2020-05-25 19:59:01 +00:00
|
|
|
hash = parse_feature_value(feature_list, "object-format", &len, NULL);
|
|
|
|
if (!hash) {
|
|
|
|
hash = hash_algos[GIT_HASH_SHA1].name;
|
|
|
|
len = strlen(hash);
|
|
|
|
}
|
|
|
|
if (xstrncmpz(the_hash_algo->name, hash, len))
|
|
|
|
die("error: unsupported object format '%s'", hash);
|
2020-11-11 23:29:34 +00:00
|
|
|
client_sid = parse_feature_value(feature_list, "session-id", &len, NULL);
|
|
|
|
if (client_sid) {
|
|
|
|
char *sid = xstrndup(client_sid, len);
|
|
|
|
trace2_data_string("transfer", NULL, "client-sid", client_sid);
|
|
|
|
free(sid);
|
|
|
|
}
|
2005-12-26 07:18:37 +00:00
|
|
|
}
|
2014-08-15 21:11:33 +00:00
|
|
|
|
2018-12-29 21:19:14 +00:00
|
|
|
if (!strcmp(reader->line, "push-cert")) {
|
push: the beginning of "git push --signed"
While signed tags and commits assert that the objects thusly signed
came from you, who signed these objects, there is not a good way to
assert that you wanted to have a particular object at the tip of a
particular branch. My signing v2.0.1 tag only means I want to call
the version v2.0.1, and it does not mean I want to push it out to my
'master' branch---it is likely that I only want it in 'maint', so
the signature on the object alone is insufficient.
The only assurance to you that 'maint' points at what I wanted to
place there comes from your trust on the hosting site and my
authentication with it, which cannot easily audited later.
Introduce a mechanism that allows you to sign a "push certificate"
(for the lack of better name) every time you push, asserting that
what object you are pushing to update which ref that used to point
at what other object. Think of it as a cryptographic protection for
ref updates, similar to signed tags/commits but working on an
orthogonal axis.
The basic flow based on this mechanism goes like this:
1. You push out your work with "git push --signed".
2. The sending side learns where the remote refs are as usual,
together with what protocol extension the receiving end
supports. If the receiving end does not advertise the protocol
extension "push-cert", an attempt to "git push --signed" fails.
Otherwise, a text file, that looks like the following, is
prepared in core:
certificate version 0.1
pusher Junio C Hamano <gitster@pobox.com> 1315427886 -0700
7339ca65... 21580ecb... refs/heads/master
3793ac56... 12850bec... refs/heads/next
The file begins with a few header lines, which may grow as we
gain more experience. The 'pusher' header records the name of
the signer (the value of user.signingkey configuration variable,
falling back to GIT_COMMITTER_{NAME|EMAIL}) and the time of the
certificate generation. After the header, a blank line follows,
followed by a copy of the protocol message lines.
Each line shows the old and the new object name at the tip of
the ref this push tries to update, in the way identical to how
the underlying "git push" protocol exchange tells the ref
updates to the receiving end (by recording the "old" object
name, the push certificate also protects against replaying). It
is expected that new command packet types other than the
old-new-refname kind will be included in push certificate in the
same way as would appear in the plain vanilla command packets in
unsigned pushes.
The user then is asked to sign this push certificate using GPG,
formatted in a way similar to how signed tag objects are signed,
and the result is sent to the other side (i.e. receive-pack).
In the protocol exchange, this step comes immediately before the
sender tells what the result of the push should be, which in
turn comes before it sends the pack data.
3. When the receiving end sees a push certificate, the certificate
is written out as a blob. The pre-receive hook can learn about
the certificate by checking GIT_PUSH_CERT environment variable,
which, if present, tells the object name of this blob, and make
the decision to allow or reject this push. Additionally, the
post-receive hook can also look at the certificate, which may be
a good place to log all the received certificates for later
audits.
Because a push certificate carry the same information as the usual
command packets in the protocol exchange, we can omit the latter
when a push certificate is in use and reduce the protocol overhead.
This however is not included in this patch to make it easier to
review (in other words, the series at this step should never be
released without the remainder of the series, as it implements an
interim protocol that will be incompatible with the final one).
As such, the documentation update for the protocol is left out of
this step.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-12 18:17:07 +00:00
|
|
|
int true_flush = 0;
|
2018-12-29 21:19:14 +00:00
|
|
|
int saved_options = reader->options;
|
|
|
|
reader->options &= ~PACKET_READ_CHOMP_NEWLINE;
|
push: the beginning of "git push --signed"
While signed tags and commits assert that the objects thusly signed
came from you, who signed these objects, there is not a good way to
assert that you wanted to have a particular object at the tip of a
particular branch. My signing v2.0.1 tag only means I want to call
the version v2.0.1, and it does not mean I want to push it out to my
'master' branch---it is likely that I only want it in 'maint', so
the signature on the object alone is insufficient.
The only assurance to you that 'maint' points at what I wanted to
place there comes from your trust on the hosting site and my
authentication with it, which cannot easily audited later.
Introduce a mechanism that allows you to sign a "push certificate"
(for the lack of better name) every time you push, asserting that
what object you are pushing to update which ref that used to point
at what other object. Think of it as a cryptographic protection for
ref updates, similar to signed tags/commits but working on an
orthogonal axis.
The basic flow based on this mechanism goes like this:
1. You push out your work with "git push --signed".
2. The sending side learns where the remote refs are as usual,
together with what protocol extension the receiving end
supports. If the receiving end does not advertise the protocol
extension "push-cert", an attempt to "git push --signed" fails.
Otherwise, a text file, that looks like the following, is
prepared in core:
certificate version 0.1
pusher Junio C Hamano <gitster@pobox.com> 1315427886 -0700
7339ca65... 21580ecb... refs/heads/master
3793ac56... 12850bec... refs/heads/next
The file begins with a few header lines, which may grow as we
gain more experience. The 'pusher' header records the name of
the signer (the value of user.signingkey configuration variable,
falling back to GIT_COMMITTER_{NAME|EMAIL}) and the time of the
certificate generation. After the header, a blank line follows,
followed by a copy of the protocol message lines.
Each line shows the old and the new object name at the tip of
the ref this push tries to update, in the way identical to how
the underlying "git push" protocol exchange tells the ref
updates to the receiving end (by recording the "old" object
name, the push certificate also protects against replaying). It
is expected that new command packet types other than the
old-new-refname kind will be included in push certificate in the
same way as would appear in the plain vanilla command packets in
unsigned pushes.
The user then is asked to sign this push certificate using GPG,
formatted in a way similar to how signed tag objects are signed,
and the result is sent to the other side (i.e. receive-pack).
In the protocol exchange, this step comes immediately before the
sender tells what the result of the push should be, which in
turn comes before it sends the pack data.
3. When the receiving end sees a push certificate, the certificate
is written out as a blob. The pre-receive hook can learn about
the certificate by checking GIT_PUSH_CERT environment variable,
which, if present, tells the object name of this blob, and make
the decision to allow or reject this push. Additionally, the
post-receive hook can also look at the certificate, which may be
a good place to log all the received certificates for later
audits.
Because a push certificate carry the same information as the usual
command packets in the protocol exchange, we can omit the latter
when a push certificate is in use and reduce the protocol overhead.
This however is not included in this patch to make it easier to
review (in other words, the series at this step should never be
released without the remainder of the series, as it implements an
interim protocol that will be incompatible with the final one).
As such, the documentation update for the protocol is left out of
this step.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-12 18:17:07 +00:00
|
|
|
|
|
|
|
for (;;) {
|
2018-12-29 21:19:14 +00:00
|
|
|
packet_reader_read(reader);
|
|
|
|
if (reader->status == PACKET_READ_FLUSH) {
|
push: the beginning of "git push --signed"
While signed tags and commits assert that the objects thusly signed
came from you, who signed these objects, there is not a good way to
assert that you wanted to have a particular object at the tip of a
particular branch. My signing v2.0.1 tag only means I want to call
the version v2.0.1, and it does not mean I want to push it out to my
'master' branch---it is likely that I only want it in 'maint', so
the signature on the object alone is insufficient.
The only assurance to you that 'maint' points at what I wanted to
place there comes from your trust on the hosting site and my
authentication with it, which cannot easily audited later.
Introduce a mechanism that allows you to sign a "push certificate"
(for the lack of better name) every time you push, asserting that
what object you are pushing to update which ref that used to point
at what other object. Think of it as a cryptographic protection for
ref updates, similar to signed tags/commits but working on an
orthogonal axis.
The basic flow based on this mechanism goes like this:
1. You push out your work with "git push --signed".
2. The sending side learns where the remote refs are as usual,
together with what protocol extension the receiving end
supports. If the receiving end does not advertise the protocol
extension "push-cert", an attempt to "git push --signed" fails.
Otherwise, a text file, that looks like the following, is
prepared in core:
certificate version 0.1
pusher Junio C Hamano <gitster@pobox.com> 1315427886 -0700
7339ca65... 21580ecb... refs/heads/master
3793ac56... 12850bec... refs/heads/next
The file begins with a few header lines, which may grow as we
gain more experience. The 'pusher' header records the name of
the signer (the value of user.signingkey configuration variable,
falling back to GIT_COMMITTER_{NAME|EMAIL}) and the time of the
certificate generation. After the header, a blank line follows,
followed by a copy of the protocol message lines.
Each line shows the old and the new object name at the tip of
the ref this push tries to update, in the way identical to how
the underlying "git push" protocol exchange tells the ref
updates to the receiving end (by recording the "old" object
name, the push certificate also protects against replaying). It
is expected that new command packet types other than the
old-new-refname kind will be included in push certificate in the
same way as would appear in the plain vanilla command packets in
unsigned pushes.
The user then is asked to sign this push certificate using GPG,
formatted in a way similar to how signed tag objects are signed,
and the result is sent to the other side (i.e. receive-pack).
In the protocol exchange, this step comes immediately before the
sender tells what the result of the push should be, which in
turn comes before it sends the pack data.
3. When the receiving end sees a push certificate, the certificate
is written out as a blob. The pre-receive hook can learn about
the certificate by checking GIT_PUSH_CERT environment variable,
which, if present, tells the object name of this blob, and make
the decision to allow or reject this push. Additionally, the
post-receive hook can also look at the certificate, which may be
a good place to log all the received certificates for later
audits.
Because a push certificate carry the same information as the usual
command packets in the protocol exchange, we can omit the latter
when a push certificate is in use and reduce the protocol overhead.
This however is not included in this patch to make it easier to
review (in other words, the series at this step should never be
released without the remainder of the series, as it implements an
interim protocol that will be incompatible with the final one).
As such, the documentation update for the protocol is left out of
this step.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-12 18:17:07 +00:00
|
|
|
true_flush = 1;
|
|
|
|
break;
|
|
|
|
}
|
2018-12-29 21:19:14 +00:00
|
|
|
if (reader->status != PACKET_READ_NORMAL) {
|
|
|
|
die("protocol error: got an unexpected packet");
|
|
|
|
}
|
|
|
|
if (!strcmp(reader->line, "push-cert-end\n"))
|
push: the beginning of "git push --signed"
While signed tags and commits assert that the objects thusly signed
came from you, who signed these objects, there is not a good way to
assert that you wanted to have a particular object at the tip of a
particular branch. My signing v2.0.1 tag only means I want to call
the version v2.0.1, and it does not mean I want to push it out to my
'master' branch---it is likely that I only want it in 'maint', so
the signature on the object alone is insufficient.
The only assurance to you that 'maint' points at what I wanted to
place there comes from your trust on the hosting site and my
authentication with it, which cannot easily audited later.
Introduce a mechanism that allows you to sign a "push certificate"
(for the lack of better name) every time you push, asserting that
what object you are pushing to update which ref that used to point
at what other object. Think of it as a cryptographic protection for
ref updates, similar to signed tags/commits but working on an
orthogonal axis.
The basic flow based on this mechanism goes like this:
1. You push out your work with "git push --signed".
2. The sending side learns where the remote refs are as usual,
together with what protocol extension the receiving end
supports. If the receiving end does not advertise the protocol
extension "push-cert", an attempt to "git push --signed" fails.
Otherwise, a text file, that looks like the following, is
prepared in core:
certificate version 0.1
pusher Junio C Hamano <gitster@pobox.com> 1315427886 -0700
7339ca65... 21580ecb... refs/heads/master
3793ac56... 12850bec... refs/heads/next
The file begins with a few header lines, which may grow as we
gain more experience. The 'pusher' header records the name of
the signer (the value of user.signingkey configuration variable,
falling back to GIT_COMMITTER_{NAME|EMAIL}) and the time of the
certificate generation. After the header, a blank line follows,
followed by a copy of the protocol message lines.
Each line shows the old and the new object name at the tip of
the ref this push tries to update, in the way identical to how
the underlying "git push" protocol exchange tells the ref
updates to the receiving end (by recording the "old" object
name, the push certificate also protects against replaying). It
is expected that new command packet types other than the
old-new-refname kind will be included in push certificate in the
same way as would appear in the plain vanilla command packets in
unsigned pushes.
The user then is asked to sign this push certificate using GPG,
formatted in a way similar to how signed tag objects are signed,
and the result is sent to the other side (i.e. receive-pack).
In the protocol exchange, this step comes immediately before the
sender tells what the result of the push should be, which in
turn comes before it sends the pack data.
3. When the receiving end sees a push certificate, the certificate
is written out as a blob. The pre-receive hook can learn about
the certificate by checking GIT_PUSH_CERT environment variable,
which, if present, tells the object name of this blob, and make
the decision to allow or reject this push. Additionally, the
post-receive hook can also look at the certificate, which may be
a good place to log all the received certificates for later
audits.
Because a push certificate carry the same information as the usual
command packets in the protocol exchange, we can omit the latter
when a push certificate is in use and reduce the protocol overhead.
This however is not included in this patch to make it easier to
review (in other words, the series at this step should never be
released without the remainder of the series, as it implements an
interim protocol that will be incompatible with the final one).
As such, the documentation update for the protocol is left out of
this step.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-12 18:17:07 +00:00
|
|
|
break; /* end of cert */
|
2018-12-29 21:19:14 +00:00
|
|
|
strbuf_addstr(&push_cert, reader->line);
|
push: the beginning of "git push --signed"
While signed tags and commits assert that the objects thusly signed
came from you, who signed these objects, there is not a good way to
assert that you wanted to have a particular object at the tip of a
particular branch. My signing v2.0.1 tag only means I want to call
the version v2.0.1, and it does not mean I want to push it out to my
'master' branch---it is likely that I only want it in 'maint', so
the signature on the object alone is insufficient.
The only assurance to you that 'maint' points at what I wanted to
place there comes from your trust on the hosting site and my
authentication with it, which cannot easily audited later.
Introduce a mechanism that allows you to sign a "push certificate"
(for the lack of better name) every time you push, asserting that
what object you are pushing to update which ref that used to point
at what other object. Think of it as a cryptographic protection for
ref updates, similar to signed tags/commits but working on an
orthogonal axis.
The basic flow based on this mechanism goes like this:
1. You push out your work with "git push --signed".
2. The sending side learns where the remote refs are as usual,
together with what protocol extension the receiving end
supports. If the receiving end does not advertise the protocol
extension "push-cert", an attempt to "git push --signed" fails.
Otherwise, a text file, that looks like the following, is
prepared in core:
certificate version 0.1
pusher Junio C Hamano <gitster@pobox.com> 1315427886 -0700
7339ca65... 21580ecb... refs/heads/master
3793ac56... 12850bec... refs/heads/next
The file begins with a few header lines, which may grow as we
gain more experience. The 'pusher' header records the name of
the signer (the value of user.signingkey configuration variable,
falling back to GIT_COMMITTER_{NAME|EMAIL}) and the time of the
certificate generation. After the header, a blank line follows,
followed by a copy of the protocol message lines.
Each line shows the old and the new object name at the tip of
the ref this push tries to update, in the way identical to how
the underlying "git push" protocol exchange tells the ref
updates to the receiving end (by recording the "old" object
name, the push certificate also protects against replaying). It
is expected that new command packet types other than the
old-new-refname kind will be included in push certificate in the
same way as would appear in the plain vanilla command packets in
unsigned pushes.
The user then is asked to sign this push certificate using GPG,
formatted in a way similar to how signed tag objects are signed,
and the result is sent to the other side (i.e. receive-pack).
In the protocol exchange, this step comes immediately before the
sender tells what the result of the push should be, which in
turn comes before it sends the pack data.
3. When the receiving end sees a push certificate, the certificate
is written out as a blob. The pre-receive hook can learn about
the certificate by checking GIT_PUSH_CERT environment variable,
which, if present, tells the object name of this blob, and make
the decision to allow or reject this push. Additionally, the
post-receive hook can also look at the certificate, which may be
a good place to log all the received certificates for later
audits.
Because a push certificate carry the same information as the usual
command packets in the protocol exchange, we can omit the latter
when a push certificate is in use and reduce the protocol overhead.
This however is not included in this patch to make it easier to
review (in other words, the series at this step should never be
released without the remainder of the series, as it implements an
interim protocol that will be incompatible with the final one).
As such, the documentation update for the protocol is left out of
this step.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-12 18:17:07 +00:00
|
|
|
}
|
2018-12-29 21:19:14 +00:00
|
|
|
reader->options = saved_options;
|
push: the beginning of "git push --signed"
While signed tags and commits assert that the objects thusly signed
came from you, who signed these objects, there is not a good way to
assert that you wanted to have a particular object at the tip of a
particular branch. My signing v2.0.1 tag only means I want to call
the version v2.0.1, and it does not mean I want to push it out to my
'master' branch---it is likely that I only want it in 'maint', so
the signature on the object alone is insufficient.
The only assurance to you that 'maint' points at what I wanted to
place there comes from your trust on the hosting site and my
authentication with it, which cannot easily audited later.
Introduce a mechanism that allows you to sign a "push certificate"
(for the lack of better name) every time you push, asserting that
what object you are pushing to update which ref that used to point
at what other object. Think of it as a cryptographic protection for
ref updates, similar to signed tags/commits but working on an
orthogonal axis.
The basic flow based on this mechanism goes like this:
1. You push out your work with "git push --signed".
2. The sending side learns where the remote refs are as usual,
together with what protocol extension the receiving end
supports. If the receiving end does not advertise the protocol
extension "push-cert", an attempt to "git push --signed" fails.
Otherwise, a text file, that looks like the following, is
prepared in core:
certificate version 0.1
pusher Junio C Hamano <gitster@pobox.com> 1315427886 -0700
7339ca65... 21580ecb... refs/heads/master
3793ac56... 12850bec... refs/heads/next
The file begins with a few header lines, which may grow as we
gain more experience. The 'pusher' header records the name of
the signer (the value of user.signingkey configuration variable,
falling back to GIT_COMMITTER_{NAME|EMAIL}) and the time of the
certificate generation. After the header, a blank line follows,
followed by a copy of the protocol message lines.
Each line shows the old and the new object name at the tip of
the ref this push tries to update, in the way identical to how
the underlying "git push" protocol exchange tells the ref
updates to the receiving end (by recording the "old" object
name, the push certificate also protects against replaying). It
is expected that new command packet types other than the
old-new-refname kind will be included in push certificate in the
same way as would appear in the plain vanilla command packets in
unsigned pushes.
The user then is asked to sign this push certificate using GPG,
formatted in a way similar to how signed tag objects are signed,
and the result is sent to the other side (i.e. receive-pack).
In the protocol exchange, this step comes immediately before the
sender tells what the result of the push should be, which in
turn comes before it sends the pack data.
3. When the receiving end sees a push certificate, the certificate
is written out as a blob. The pre-receive hook can learn about
the certificate by checking GIT_PUSH_CERT environment variable,
which, if present, tells the object name of this blob, and make
the decision to allow or reject this push. Additionally, the
post-receive hook can also look at the certificate, which may be
a good place to log all the received certificates for later
audits.
Because a push certificate carry the same information as the usual
command packets in the protocol exchange, we can omit the latter
when a push certificate is in use and reduce the protocol overhead.
This however is not included in this patch to make it easier to
review (in other words, the series at this step should never be
released without the remainder of the series, as it implements an
interim protocol that will be incompatible with the final one).
As such, the documentation update for the protocol is left out of
this step.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-12 18:17:07 +00:00
|
|
|
|
|
|
|
if (true_flush)
|
|
|
|
break;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2018-12-29 21:19:14 +00:00
|
|
|
p = queue_command(p, reader->line, linelen);
|
2005-06-30 00:52:11 +00:00
|
|
|
}
|
2014-08-18 21:38:45 +00:00
|
|
|
|
|
|
|
if (push_cert.len)
|
|
|
|
queue_commands_from_cert(p, &push_cert);
|
|
|
|
|
2010-04-19 22:08:30 +00:00
|
|
|
return commands;
|
2005-06-30 00:52:11 +00:00
|
|
|
}
|
|
|
|
|
2018-12-29 21:19:14 +00:00
|
|
|
static void read_push_options(struct packet_reader *reader,
|
|
|
|
struct string_list *options)
|
2016-07-14 21:49:46 +00:00
|
|
|
{
|
|
|
|
while (1) {
|
2018-12-29 21:19:14 +00:00
|
|
|
if (packet_reader_read(reader) != PACKET_READ_NORMAL)
|
2016-07-14 21:49:46 +00:00
|
|
|
break;
|
|
|
|
|
2018-12-29 21:19:14 +00:00
|
|
|
string_list_append(options, reader->line);
|
2016-07-14 21:49:46 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-11-01 22:06:21 +00:00
|
|
|
static const char *parse_pack_header(struct pack_header *hdr)
|
|
|
|
{
|
2007-01-23 05:55:18 +00:00
|
|
|
switch (read_pack_header(0, hdr)) {
|
|
|
|
case PH_ERROR_EOF:
|
|
|
|
return "eof before pack header was fully read";
|
|
|
|
|
|
|
|
case PH_ERROR_PACK_SIGNATURE:
|
2006-11-01 22:06:21 +00:00
|
|
|
return "protocol error (pack signature mismatch detected)";
|
2007-01-23 05:55:18 +00:00
|
|
|
|
|
|
|
case PH_ERROR_PROTOCOL:
|
2006-11-01 22:06:21 +00:00
|
|
|
return "protocol error (pack version unsupported)";
|
2007-01-23 05:55:18 +00:00
|
|
|
|
|
|
|
default:
|
|
|
|
return "unknown error in parse_pack_header";
|
|
|
|
|
|
|
|
case 0:
|
|
|
|
return NULL;
|
|
|
|
}
|
2006-11-01 22:06:21 +00:00
|
|
|
}
|
|
|
|
|
2023-03-10 06:52:10 +00:00
|
|
|
static struct tempfile *pack_lockfile;
|
2006-11-01 22:06:25 +00:00
|
|
|
|
2020-07-28 20:24:27 +00:00
|
|
|
static void push_header_arg(struct strvec *args, struct pack_header *hdr)
|
2017-03-28 19:46:47 +00:00
|
|
|
{
|
2020-07-28 20:24:27 +00:00
|
|
|
strvec_pushf(args, "--pack_header=%"PRIu32",%"PRIu32,
|
strvec: fix indentation in renamed calls
Code which split an argv_array call across multiple lines, like:
argv_array_pushl(&args, "one argument",
"another argument", "and more",
NULL);
was recently mechanically renamed to use strvec, which results in
mis-matched indentation like:
strvec_pushl(&args, "one argument",
"another argument", "and more",
NULL);
Let's fix these up to align the arguments with the opening paren. I did
this manually by sifting through the results of:
git jump grep 'strvec_.*,$'
and liberally applying my editor's auto-format. Most of the changes are
of the form shown above, though I also normalized a few that had
originally used a single-tab indentation (rather than our usual style of
aligning with the open paren). I also rewrapped a couple of obvious
cases (e.g., where previously too-long lines became short enough to fit
on one), but I wasn't aggressive about it. In cases broken to three or
more lines, the grouping of arguments is sometimes meaningful, and it
wasn't worth my time or reviewer time to ponder each case individually.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-28 20:26:31 +00:00
|
|
|
ntohl(hdr->hdr_version), ntohl(hdr->hdr_entries));
|
2017-03-28 19:46:47 +00:00
|
|
|
}
|
|
|
|
|
2013-12-05 13:02:44 +00:00
|
|
|
static const char *unpack(int err_fd, struct shallow_info *si)
|
2005-06-30 00:52:11 +00:00
|
|
|
{
|
2006-11-01 22:06:21 +00:00
|
|
|
struct pack_header hdr;
|
|
|
|
const char *hdr_err;
|
2013-12-05 13:02:43 +00:00
|
|
|
int status;
|
2014-08-19 19:09:35 +00:00
|
|
|
struct child_process child = CHILD_PROCESS_INIT;
|
2011-09-04 19:37:45 +00:00
|
|
|
int fsck_objects = (receive_fsck_objects >= 0
|
|
|
|
? receive_fsck_objects
|
|
|
|
: transfer_fsck_objects >= 0
|
|
|
|
? transfer_fsck_objects
|
|
|
|
: 0);
|
2006-11-01 22:06:21 +00:00
|
|
|
|
|
|
|
hdr_err = parse_pack_header(&hdr);
|
receive-pack: close sideband fd on early pack errors
Since commit a22e6f8 (receive-pack: send pack-processing
stderr over sideband, 2012-09-21), receive-pack will start
an async sideband thread to copy the stderr from our
index-pack or unpack-objects child to the client. We hand
the thread's input descriptor to unpack(), which puts it in
the "err" member of the "struct child_process".
After unpack() returns, we use finish_async() to reap the
sideband thread. The thread is only ready to die when it
gets EOF on its pipe, which is connected to the err
descriptor. So we expect all of the write ends of that pipe
to be closed as part of unpack().
Normally, this works fine. After start_command forks, it
closes the parent copy of the descriptor. Then once the
child exits (whether it was successful or not), that closes
the only remaining writer.
However, there is one code-path in unpack() that does not
handle this. Before we decide which of unpack-objects or
index-pack to use, we read the pack header ourselves to see
how many objects it contains. If there is an error here, we
exit without running either sub-command, the pipe descriptor
remains open, and we are in a deadlock, waiting for the
sideband thread to die (which is in turn waiting for us to
close the pipe).
We can fix this by making sure that unpack() always closes
the pipe before returning.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-19 21:24:29 +00:00
|
|
|
if (hdr_err) {
|
|
|
|
if (err_fd > 0)
|
|
|
|
close(err_fd);
|
2006-11-01 22:06:21 +00:00
|
|
|
return hdr_err;
|
receive-pack: close sideband fd on early pack errors
Since commit a22e6f8 (receive-pack: send pack-processing
stderr over sideband, 2012-09-21), receive-pack will start
an async sideband thread to copy the stderr from our
index-pack or unpack-objects child to the client. We hand
the thread's input descriptor to unpack(), which puts it in
the "err" member of the "struct child_process".
After unpack() returns, we use finish_async() to reap the
sideband thread. The thread is only ready to die when it
gets EOF on its pipe, which is connected to the err
descriptor. So we expect all of the write ends of that pipe
to be closed as part of unpack().
Normally, this works fine. After start_command forks, it
closes the parent copy of the descriptor. Then once the
child exits (whether it was successful or not), that closes
the only remaining writer.
However, there is one code-path in unpack() that does not
handle this. Before we decide which of unpack-objects or
index-pack to use, we read the pack header ourselves to see
how many objects it contains. If there is an error here, we
exit without running either sub-command, the pipe descriptor
remains open, and we are in a deadlock, waiting for the
sideband thread to die (which is in turn waiting for us to
close the pipe).
We can fix this by making sure that unpack() always closes
the pipe before returning.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-19 21:24:29 +00:00
|
|
|
}
|
2006-11-01 22:06:21 +00:00
|
|
|
|
2013-12-05 13:02:44 +00:00
|
|
|
if (si->nr_ours || si->nr_theirs) {
|
|
|
|
alt_shallow_file = setup_temporary_shallow(si->shallow);
|
2020-07-28 20:24:27 +00:00
|
|
|
strvec_push(&child.args, "--shallow-file");
|
|
|
|
strvec_push(&child.args, alt_shallow_file);
|
2013-12-05 13:02:44 +00:00
|
|
|
}
|
|
|
|
|
2021-12-06 22:05:04 +00:00
|
|
|
tmp_objdir = tmp_objdir_create("incoming");
|
2017-03-07 13:35:34 +00:00
|
|
|
if (!tmp_objdir) {
|
|
|
|
if (err_fd > 0)
|
|
|
|
close(err_fd);
|
2016-10-03 20:49:14 +00:00
|
|
|
return "unable to create temporary object directory";
|
2017-03-07 13:35:34 +00:00
|
|
|
}
|
2022-06-10 22:04:13 +00:00
|
|
|
strvec_pushv(&child.env, tmp_objdir_env(tmp_objdir));
|
2016-10-03 20:49:14 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Normally we just pass the tmp_objdir environment to the child
|
|
|
|
* processes that do the heavy lifting, but we may need to see these
|
|
|
|
* objects ourselves to set up shallow information.
|
|
|
|
*/
|
|
|
|
tmp_objdir_add_as_alternate(tmp_objdir);
|
|
|
|
|
2006-11-01 22:06:21 +00:00
|
|
|
if (ntohl(hdr.hdr_entries) < unpack_limit) {
|
2020-07-28 20:24:27 +00:00
|
|
|
strvec_push(&child.args, "unpack-objects");
|
2017-03-28 19:46:47 +00:00
|
|
|
push_header_arg(&child.args, &hdr);
|
2012-01-08 21:06:20 +00:00
|
|
|
if (quiet)
|
2020-07-28 20:24:27 +00:00
|
|
|
strvec_push(&child.args, "-q");
|
2011-09-04 19:37:45 +00:00
|
|
|
if (fsck_objects)
|
2020-07-28 20:24:27 +00:00
|
|
|
strvec_pushf(&child.args, "--strict%s",
|
strvec: fix indentation in renamed calls
Code which split an argv_array call across multiple lines, like:
argv_array_pushl(&args, "one argument",
"another argument", "and more",
NULL);
was recently mechanically renamed to use strvec, which results in
mis-matched indentation like:
strvec_pushl(&args, "one argument",
"another argument", "and more",
NULL);
Let's fix these up to align the arguments with the opening paren. I did
this manually by sifting through the results of:
git jump grep 'strvec_.*,$'
and liberally applying my editor's auto-format. Most of the changes are
of the form shown above, though I also normalized a few that had
originally used a single-tab indentation (rather than our usual style of
aligning with the open paren). I also rewrapped a couple of obvious
cases (e.g., where previously too-long lines became short enough to fit
on one), but I wasn't aggressive about it. In cases broken to three or
more lines, the grouping of arguments is sometimes meaningful, and it
wasn't worth my time or reviewer time to ponder each case individually.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-28 20:26:31 +00:00
|
|
|
fsck_msg_types.buf);
|
2016-08-24 18:41:57 +00:00
|
|
|
if (max_input_size)
|
2020-07-28 20:24:27 +00:00
|
|
|
strvec_pushf(&child.args, "--max-input-size=%"PRIuMAX,
|
strvec: fix indentation in renamed calls
Code which split an argv_array call across multiple lines, like:
argv_array_pushl(&args, "one argument",
"another argument", "and more",
NULL);
was recently mechanically renamed to use strvec, which results in
mis-matched indentation like:
strvec_pushl(&args, "one argument",
"another argument", "and more",
NULL);
Let's fix these up to align the arguments with the opening paren. I did
this manually by sifting through the results of:
git jump grep 'strvec_.*,$'
and liberally applying my editor's auto-format. Most of the changes are
of the form shown above, though I also normalized a few that had
originally used a single-tab indentation (rather than our usual style of
aligning with the open paren). I also rewrapped a couple of obvious
cases (e.g., where previously too-long lines became short enough to fit
on one), but I wasn't aggressive about it. In cases broken to three or
more lines, the grouping of arguments is sometimes meaningful, and it
wasn't worth my time or reviewer time to ponder each case individually.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-28 20:26:31 +00:00
|
|
|
(uintmax_t)max_input_size);
|
2012-09-21 05:32:52 +00:00
|
|
|
child.no_stdout = 1;
|
receive-pack: send pack-processing stderr over sideband
Receive-pack invokes either unpack-objects or index-pack to
handle the incoming pack. However, we do not redirect the
stderr of the sub-processes at all, so it is never seen by
the client. From the initial thread adding sideband support,
which is here:
http://thread.gmane.org/gmane.comp.version-control.git/139471
it is clear that some messages are specifically kept off the
sideband (with the assumption that they are of interest only
to an administrator, not the client). The stderr of the
subprocesses is mentioned in the thread, but it's unclear if
they are included in that group, or were simply forgotten.
However, there are a few good reasons to show them to the
client:
1. In many cases, they are directly about the incoming
packfile (e.g., fsck warnings with --strict, corruption
in the packfile, etc). Without these messages, the
client just gets "unpacker error" with no extra useful
diagnosis.
2. No matter what the cause, we are probably better off
showing the errors to the client. If the client and the
server admin are not the same entity, it is probably
much easier for the client to cut-and-paste the errors
they see than for the admin to try to dig them out of a
log and correlate them with a particular session.
3. Users of the ssh transport typically already see these
stderr messages, as the remote's stderr is copied
literally by ssh. This brings other transports (http,
and push-over-git if you are crazy enough to enable it)
more in line with ssh. As a bonus for ssh users,
because the messages are now fed through the sideband
and printed by the local git, they will have "remote:"
prepended and be properly interleaved with any local
output to stderr.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-21 05:34:55 +00:00
|
|
|
child.err = err_fd;
|
2012-09-21 05:32:52 +00:00
|
|
|
child.git_cmd = 1;
|
2013-12-05 13:02:43 +00:00
|
|
|
status = run_command(&child);
|
|
|
|
if (status)
|
|
|
|
return "unpack-objects abnormal exit";
|
2006-11-01 22:06:25 +00:00
|
|
|
} else {
|
2017-04-18 21:57:42 +00:00
|
|
|
char hostname[HOST_NAME_MAX + 1];
|
2023-03-10 06:52:10 +00:00
|
|
|
char *lockfile;
|
2006-11-01 22:06:25 +00:00
|
|
|
|
2020-07-28 20:24:27 +00:00
|
|
|
strvec_pushl(&child.args, "index-pack", "--stdin", NULL);
|
2017-03-28 19:46:47 +00:00
|
|
|
push_header_arg(&child.args, &hdr);
|
2015-09-24 21:08:14 +00:00
|
|
|
|
2017-04-18 21:57:43 +00:00
|
|
|
if (xgethostname(hostname, sizeof(hostname)))
|
2015-09-24 21:08:14 +00:00
|
|
|
xsnprintf(hostname, sizeof(hostname), "localhost");
|
2020-07-28 20:24:27 +00:00
|
|
|
strvec_pushf(&child.args,
|
strvec: fix indentation in renamed calls
Code which split an argv_array call across multiple lines, like:
argv_array_pushl(&args, "one argument",
"another argument", "and more",
NULL);
was recently mechanically renamed to use strvec, which results in
mis-matched indentation like:
strvec_pushl(&args, "one argument",
"another argument", "and more",
NULL);
Let's fix these up to align the arguments with the opening paren. I did
this manually by sifting through the results of:
git jump grep 'strvec_.*,$'
and liberally applying my editor's auto-format. Most of the changes are
of the form shown above, though I also normalized a few that had
originally used a single-tab indentation (rather than our usual style of
aligning with the open paren). I also rewrapped a couple of obvious
cases (e.g., where previously too-long lines became short enough to fit
on one), but I wasn't aggressive about it. In cases broken to three or
more lines, the grouping of arguments is sometimes meaningful, and it
wasn't worth my time or reviewer time to ponder each case individually.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-28 20:26:31 +00:00
|
|
|
"--keep=receive-pack %"PRIuMAX" on %s",
|
|
|
|
(uintmax_t)getpid(),
|
|
|
|
hostname);
|
2015-09-24 21:08:14 +00:00
|
|
|
|
2016-07-15 10:35:28 +00:00
|
|
|
if (!quiet && err_fd)
|
2020-07-28 20:24:27 +00:00
|
|
|
strvec_push(&child.args, "--show-resolving-progress");
|
receive-pack: send keepalives during quiet periods
After a client has sent us the complete pack, we may spend
some time processing the data and running hooks. If the
client asked us to be quiet, receive-pack won't send any
progress data during the index-pack or connectivity-check
steps. And hooks may or may not produce their own progress
output. In these cases, the network connection is totally
silent from both ends.
Git itself doesn't care about this (it will wait forever),
but other parts of the system (e.g., firewalls,
load-balancers, etc) might hang up the connection. So we'd
like to send some sort of keepalive to let the network and
the client side know that we're still alive and processing.
We can use the same trick we did in 05e9515 (upload-pack:
send keepalive packets during pack computation, 2013-09-08).
Namely, we will send an empty sideband data packet every `N`
seconds that we do not relay any stderr data over the
sideband channel. As with 05e9515, this means that we won't
bother sending keepalives when there's actual progress data,
but will kick in when it has been disabled (or if there is a
lull in the progress data).
The concept is simple, but the details are subtle enough
that they need discussing here.
Before the client sends us the pack, we don't want to do any
keepalives. We'll have sent our ref advertisement, and we're
waiting for them to send us the pack (and tell us that they
support sidebands at all).
While we're receiving the pack from the client (or waiting
for it to start), there's no need for keepalives; it's up to
them to keep the connection active by sending data.
Moreover, it would be wrong for us to do so. When we are the
server in the smart-http protocol, we must treat our
connection as half-duplex. So any keepalives we send while
receiving the pack would potentially be buffered by the
webserver. Not only does this make them useless (since they
would not be delivered in a timely manner), but it could
actually cause a deadlock if we fill up the buffer with
keepalives. (It wouldn't be wrong to send keepalives in this
phase for a full-duplex connection like ssh; it's simply
pointless, as it is the client's responsibility to speak).
As soon as we've gotten all of the pack data, then the
client is waiting for us to speak, and we should start
keepalives immediately. From here until the end of the
connection, we send one any time we are not otherwise
sending data.
But there's a catch. Receive-pack doesn't know the moment
we've gotten all the data. It passes the descriptor to
index-pack, who reads all of the data, and then starts
resolving the deltas. We have to communicate that back.
To make this work, we instruct the sideband muxer to enable
keepalives in three phases:
1. In the beginning, not at all.
2. While reading from index-pack, wait for a signal
indicating end-of-input, and then start them.
3. Afterwards, always.
The signal from index-pack in phase 2 has to come over the
stderr channel which the muxer is reading. We can't use an
extra pipe because the portable run-command interface only
gives us stderr and stdout.
Stdout is already used to pass the .keep filename back to
receive-pack. We could also send a signal there, but then we
would find out about it in the main thread. And the
keepalive needs to be done by the async muxer thread (since
it's the one writing sideband data back to the client). And
we can't reliably signal the async thread from the main
thread, because the async code sometimes uses threads and
sometimes uses forked processes.
Therefore the signal must come over the stderr channel,
where it may be interspersed with other random
human-readable messages from index-pack. This patch makes
the signal a single NUL byte. This is easy to parse, should
not appear in any normal stderr output, and we don't have to
worry about any timing issues (like seeing half the signal
bytes in one read(), and half in a subsequent one).
This is a bit ugly, but it's simple to code and should work
reliably.
Another option would be to stop using an async thread for
muxing entirely, and just poll() both stderr and stdout of
index-pack from the main thread. This would work for
index-pack (because we aren't doing anything useful in the
main thread while it runs anyway). But it would make the
connectivity check and the hook muxers much more
complicated, as they need to simultaneously feed the
sub-programs while reading their stderr.
The index-pack phase is the only one that needs this
signaling, so it could simply behave differently than the
other two. That would mean having two separate
implementations of copy_to_sideband (and the keepalive
code), though. And it still doesn't get rid of the
signaling; it just means we can write a nicer message like
"END_OF_INPUT" or something on stdout, since we don't have
to worry about separating it from the stderr cruft.
One final note: this signaling trick is only done with
index-pack, not with unpack-objects. There's no point in
doing it for the latter, because by definition it only kicks
in for a small number of objects, where keepalives are not
as useful (and this conveniently lets us avoid duplicating
the implementation).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-15 10:43:47 +00:00
|
|
|
if (use_sideband)
|
2020-07-28 20:24:27 +00:00
|
|
|
strvec_push(&child.args, "--report-end-of-input");
|
2011-09-04 19:37:45 +00:00
|
|
|
if (fsck_objects)
|
2020-07-28 20:24:27 +00:00
|
|
|
strvec_pushf(&child.args, "--strict%s",
|
strvec: fix indentation in renamed calls
Code which split an argv_array call across multiple lines, like:
argv_array_pushl(&args, "one argument",
"another argument", "and more",
NULL);
was recently mechanically renamed to use strvec, which results in
mis-matched indentation like:
strvec_pushl(&args, "one argument",
"another argument", "and more",
NULL);
Let's fix these up to align the arguments with the opening paren. I did
this manually by sifting through the results of:
git jump grep 'strvec_.*,$'
and liberally applying my editor's auto-format. Most of the changes are
of the form shown above, though I also normalized a few that had
originally used a single-tab indentation (rather than our usual style of
aligning with the open paren). I also rewrapped a couple of obvious
cases (e.g., where previously too-long lines became short enough to fit
on one), but I wasn't aggressive about it. In cases broken to three or
more lines, the grouping of arguments is sometimes meaningful, and it
wasn't worth my time or reviewer time to ponder each case individually.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-28 20:26:31 +00:00
|
|
|
fsck_msg_types.buf);
|
2016-03-01 20:21:01 +00:00
|
|
|
if (!reject_thin)
|
2020-07-28 20:24:27 +00:00
|
|
|
strvec_push(&child.args, "--fix-thin");
|
2016-08-24 18:41:57 +00:00
|
|
|
if (max_input_size)
|
2020-07-28 20:24:27 +00:00
|
|
|
strvec_pushf(&child.args, "--max-input-size=%"PRIuMAX,
|
strvec: fix indentation in renamed calls
Code which split an argv_array call across multiple lines, like:
argv_array_pushl(&args, "one argument",
"another argument", "and more",
NULL);
was recently mechanically renamed to use strvec, which results in
mis-matched indentation like:
strvec_pushl(&args, "one argument",
"another argument", "and more",
NULL);
Let's fix these up to align the arguments with the opening paren. I did
this manually by sifting through the results of:
git jump grep 'strvec_.*,$'
and liberally applying my editor's auto-format. Most of the changes are
of the form shown above, though I also normalized a few that had
originally used a single-tab indentation (rather than our usual style of
aligning with the open paren). I also rewrapped a couple of obvious
cases (e.g., where previously too-long lines became short enough to fit
on one), but I wasn't aggressive about it. In cases broken to three or
more lines, the grouping of arguments is sometimes meaningful, and it
wasn't worth my time or reviewer time to ponder each case individually.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-28 20:26:31 +00:00
|
|
|
(uintmax_t)max_input_size);
|
2013-12-05 13:02:43 +00:00
|
|
|
child.out = -1;
|
|
|
|
child.err = err_fd;
|
|
|
|
child.git_cmd = 1;
|
|
|
|
status = start_command(&child);
|
|
|
|
if (status)
|
2006-11-01 22:06:25 +00:00
|
|
|
return "index-pack fork failed";
|
2023-03-10 06:52:10 +00:00
|
|
|
|
|
|
|
lockfile = index_pack_lockfile(child.out, NULL);
|
|
|
|
if (lockfile) {
|
|
|
|
pack_lockfile = register_tempfile(lockfile);
|
|
|
|
free(lockfile);
|
|
|
|
}
|
2013-12-05 13:02:43 +00:00
|
|
|
close(child.out);
|
2023-03-10 06:52:10 +00:00
|
|
|
|
2013-12-05 13:02:43 +00:00
|
|
|
status = finish_command(&child);
|
|
|
|
if (status)
|
|
|
|
return "index-pack abnormal exit";
|
2018-03-23 17:45:21 +00:00
|
|
|
reprepare_packed_git(the_repository);
|
2005-12-26 07:18:37 +00:00
|
|
|
}
|
2013-12-05 13:02:43 +00:00
|
|
|
return NULL;
|
2005-12-26 07:18:37 +00:00
|
|
|
}
|
|
|
|
|
2013-12-05 13:02:44 +00:00
|
|
|
static const char *unpack_with_sideband(struct shallow_info *si)
|
receive-pack: send pack-processing stderr over sideband
Receive-pack invokes either unpack-objects or index-pack to
handle the incoming pack. However, we do not redirect the
stderr of the sub-processes at all, so it is never seen by
the client. From the initial thread adding sideband support,
which is here:
http://thread.gmane.org/gmane.comp.version-control.git/139471
it is clear that some messages are specifically kept off the
sideband (with the assumption that they are of interest only
to an administrator, not the client). The stderr of the
subprocesses is mentioned in the thread, but it's unclear if
they are included in that group, or were simply forgotten.
However, there are a few good reasons to show them to the
client:
1. In many cases, they are directly about the incoming
packfile (e.g., fsck warnings with --strict, corruption
in the packfile, etc). Without these messages, the
client just gets "unpacker error" with no extra useful
diagnosis.
2. No matter what the cause, we are probably better off
showing the errors to the client. If the client and the
server admin are not the same entity, it is probably
much easier for the client to cut-and-paste the errors
they see than for the admin to try to dig them out of a
log and correlate them with a particular session.
3. Users of the ssh transport typically already see these
stderr messages, as the remote's stderr is copied
literally by ssh. This brings other transports (http,
and push-over-git if you are crazy enough to enable it)
more in line with ssh. As a bonus for ssh users,
because the messages are now fed through the sideband
and printed by the local git, they will have "remote:"
prepended and be properly interleaved with any local
output to stderr.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-21 05:34:55 +00:00
|
|
|
{
|
|
|
|
struct async muxer;
|
|
|
|
const char *ret;
|
|
|
|
|
|
|
|
if (!use_sideband)
|
2013-12-05 13:02:44 +00:00
|
|
|
return unpack(0, si);
|
receive-pack: send pack-processing stderr over sideband
Receive-pack invokes either unpack-objects or index-pack to
handle the incoming pack. However, we do not redirect the
stderr of the sub-processes at all, so it is never seen by
the client. From the initial thread adding sideband support,
which is here:
http://thread.gmane.org/gmane.comp.version-control.git/139471
it is clear that some messages are specifically kept off the
sideband (with the assumption that they are of interest only
to an administrator, not the client). The stderr of the
subprocesses is mentioned in the thread, but it's unclear if
they are included in that group, or were simply forgotten.
However, there are a few good reasons to show them to the
client:
1. In many cases, they are directly about the incoming
packfile (e.g., fsck warnings with --strict, corruption
in the packfile, etc). Without these messages, the
client just gets "unpacker error" with no extra useful
diagnosis.
2. No matter what the cause, we are probably better off
showing the errors to the client. If the client and the
server admin are not the same entity, it is probably
much easier for the client to cut-and-paste the errors
they see than for the admin to try to dig them out of a
log and correlate them with a particular session.
3. Users of the ssh transport typically already see these
stderr messages, as the remote's stderr is copied
literally by ssh. This brings other transports (http,
and push-over-git if you are crazy enough to enable it)
more in line with ssh. As a bonus for ssh users,
because the messages are now fed through the sideband
and printed by the local git, they will have "remote:"
prepended and be properly interleaved with any local
output to stderr.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-21 05:34:55 +00:00
|
|
|
|
receive-pack: send keepalives during quiet periods
After a client has sent us the complete pack, we may spend
some time processing the data and running hooks. If the
client asked us to be quiet, receive-pack won't send any
progress data during the index-pack or connectivity-check
steps. And hooks may or may not produce their own progress
output. In these cases, the network connection is totally
silent from both ends.
Git itself doesn't care about this (it will wait forever),
but other parts of the system (e.g., firewalls,
load-balancers, etc) might hang up the connection. So we'd
like to send some sort of keepalive to let the network and
the client side know that we're still alive and processing.
We can use the same trick we did in 05e9515 (upload-pack:
send keepalive packets during pack computation, 2013-09-08).
Namely, we will send an empty sideband data packet every `N`
seconds that we do not relay any stderr data over the
sideband channel. As with 05e9515, this means that we won't
bother sending keepalives when there's actual progress data,
but will kick in when it has been disabled (or if there is a
lull in the progress data).
The concept is simple, but the details are subtle enough
that they need discussing here.
Before the client sends us the pack, we don't want to do any
keepalives. We'll have sent our ref advertisement, and we're
waiting for them to send us the pack (and tell us that they
support sidebands at all).
While we're receiving the pack from the client (or waiting
for it to start), there's no need for keepalives; it's up to
them to keep the connection active by sending data.
Moreover, it would be wrong for us to do so. When we are the
server in the smart-http protocol, we must treat our
connection as half-duplex. So any keepalives we send while
receiving the pack would potentially be buffered by the
webserver. Not only does this make them useless (since they
would not be delivered in a timely manner), but it could
actually cause a deadlock if we fill up the buffer with
keepalives. (It wouldn't be wrong to send keepalives in this
phase for a full-duplex connection like ssh; it's simply
pointless, as it is the client's responsibility to speak).
As soon as we've gotten all of the pack data, then the
client is waiting for us to speak, and we should start
keepalives immediately. From here until the end of the
connection, we send one any time we are not otherwise
sending data.
But there's a catch. Receive-pack doesn't know the moment
we've gotten all the data. It passes the descriptor to
index-pack, who reads all of the data, and then starts
resolving the deltas. We have to communicate that back.
To make this work, we instruct the sideband muxer to enable
keepalives in three phases:
1. In the beginning, not at all.
2. While reading from index-pack, wait for a signal
indicating end-of-input, and then start them.
3. Afterwards, always.
The signal from index-pack in phase 2 has to come over the
stderr channel which the muxer is reading. We can't use an
extra pipe because the portable run-command interface only
gives us stderr and stdout.
Stdout is already used to pass the .keep filename back to
receive-pack. We could also send a signal there, but then we
would find out about it in the main thread. And the
keepalive needs to be done by the async muxer thread (since
it's the one writing sideband data back to the client). And
we can't reliably signal the async thread from the main
thread, because the async code sometimes uses threads and
sometimes uses forked processes.
Therefore the signal must come over the stderr channel,
where it may be interspersed with other random
human-readable messages from index-pack. This patch makes
the signal a single NUL byte. This is easy to parse, should
not appear in any normal stderr output, and we don't have to
worry about any timing issues (like seeing half the signal
bytes in one read(), and half in a subsequent one).
This is a bit ugly, but it's simple to code and should work
reliably.
Another option would be to stop using an async thread for
muxing entirely, and just poll() both stderr and stdout of
index-pack from the main thread. This would work for
index-pack (because we aren't doing anything useful in the
main thread while it runs anyway). But it would make the
connectivity check and the hook muxers much more
complicated, as they need to simultaneously feed the
sub-programs while reading their stderr.
The index-pack phase is the only one that needs this
signaling, so it could simply behave differently than the
other two. That would mean having two separate
implementations of copy_to_sideband (and the keepalive
code), though. And it still doesn't get rid of the
signaling; it just means we can write a nicer message like
"END_OF_INPUT" or something on stdout, since we don't have
to worry about separating it from the stderr cruft.
One final note: this signaling trick is only done with
index-pack, not with unpack-objects. There's no point in
doing it for the latter, because by definition it only kicks
in for a small number of objects, where keepalives are not
as useful (and this conveniently lets us avoid duplicating
the implementation).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-15 10:43:47 +00:00
|
|
|
use_keepalive = KEEPALIVE_AFTER_NUL;
|
receive-pack: send pack-processing stderr over sideband
Receive-pack invokes either unpack-objects or index-pack to
handle the incoming pack. However, we do not redirect the
stderr of the sub-processes at all, so it is never seen by
the client. From the initial thread adding sideband support,
which is here:
http://thread.gmane.org/gmane.comp.version-control.git/139471
it is clear that some messages are specifically kept off the
sideband (with the assumption that they are of interest only
to an administrator, not the client). The stderr of the
subprocesses is mentioned in the thread, but it's unclear if
they are included in that group, or were simply forgotten.
However, there are a few good reasons to show them to the
client:
1. In many cases, they are directly about the incoming
packfile (e.g., fsck warnings with --strict, corruption
in the packfile, etc). Without these messages, the
client just gets "unpacker error" with no extra useful
diagnosis.
2. No matter what the cause, we are probably better off
showing the errors to the client. If the client and the
server admin are not the same entity, it is probably
much easier for the client to cut-and-paste the errors
they see than for the admin to try to dig them out of a
log and correlate them with a particular session.
3. Users of the ssh transport typically already see these
stderr messages, as the remote's stderr is copied
literally by ssh. This brings other transports (http,
and push-over-git if you are crazy enough to enable it)
more in line with ssh. As a bonus for ssh users,
because the messages are now fed through the sideband
and printed by the local git, they will have "remote:"
prepended and be properly interleaved with any local
output to stderr.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-21 05:34:55 +00:00
|
|
|
memset(&muxer, 0, sizeof(muxer));
|
|
|
|
muxer.proc = copy_to_sideband;
|
|
|
|
muxer.in = -1;
|
|
|
|
if (start_async(&muxer))
|
|
|
|
return NULL;
|
|
|
|
|
2013-12-05 13:02:44 +00:00
|
|
|
ret = unpack(muxer.in, si);
|
receive-pack: send pack-processing stderr over sideband
Receive-pack invokes either unpack-objects or index-pack to
handle the incoming pack. However, we do not redirect the
stderr of the sub-processes at all, so it is never seen by
the client. From the initial thread adding sideband support,
which is here:
http://thread.gmane.org/gmane.comp.version-control.git/139471
it is clear that some messages are specifically kept off the
sideband (with the assumption that they are of interest only
to an administrator, not the client). The stderr of the
subprocesses is mentioned in the thread, but it's unclear if
they are included in that group, or were simply forgotten.
However, there are a few good reasons to show them to the
client:
1. In many cases, they are directly about the incoming
packfile (e.g., fsck warnings with --strict, corruption
in the packfile, etc). Without these messages, the
client just gets "unpacker error" with no extra useful
diagnosis.
2. No matter what the cause, we are probably better off
showing the errors to the client. If the client and the
server admin are not the same entity, it is probably
much easier for the client to cut-and-paste the errors
they see than for the admin to try to dig them out of a
log and correlate them with a particular session.
3. Users of the ssh transport typically already see these
stderr messages, as the remote's stderr is copied
literally by ssh. This brings other transports (http,
and push-over-git if you are crazy enough to enable it)
more in line with ssh. As a bonus for ssh users,
because the messages are now fed through the sideband
and printed by the local git, they will have "remote:"
prepended and be properly interleaved with any local
output to stderr.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-21 05:34:55 +00:00
|
|
|
|
|
|
|
finish_async(&muxer);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2019-05-09 21:31:39 +00:00
|
|
|
static void prepare_shallow_update(struct shallow_info *si)
|
2013-12-05 13:02:47 +00:00
|
|
|
{
|
2017-07-08 10:35:35 +00:00
|
|
|
int i, j, k, bitmap_size = DIV_ROUND_UP(si->ref->nr, 32);
|
2013-12-05 13:02:47 +00:00
|
|
|
|
2016-02-22 22:44:25 +00:00
|
|
|
ALLOC_ARRAY(si->used_shallow, si->shallow->nr);
|
2013-12-05 13:02:47 +00:00
|
|
|
assign_shallow_commits_to_refs(si, si->used_shallow, NULL);
|
|
|
|
|
2021-03-15 22:05:04 +00:00
|
|
|
CALLOC_ARRAY(si->need_reachability_test, si->shallow->nr);
|
|
|
|
CALLOC_ARRAY(si->reachable, si->shallow->nr);
|
|
|
|
CALLOC_ARRAY(si->shallow_ref, si->ref->nr);
|
2013-12-05 13:02:47 +00:00
|
|
|
|
|
|
|
for (i = 0; i < si->nr_ours; i++)
|
|
|
|
si->need_reachability_test[si->ours[i]] = 1;
|
|
|
|
|
|
|
|
for (i = 0; i < si->shallow->nr; i++) {
|
|
|
|
if (!si->used_shallow[i])
|
|
|
|
continue;
|
|
|
|
for (j = 0; j < bitmap_size; j++) {
|
|
|
|
if (!si->used_shallow[i][j])
|
|
|
|
continue;
|
|
|
|
si->need_reachability_test[i]++;
|
|
|
|
for (k = 0; k < 32; k++)
|
2015-12-29 06:35:46 +00:00
|
|
|
if (si->used_shallow[i][j] & (1U << k))
|
2013-12-05 13:02:47 +00:00
|
|
|
si->shallow_ref[j * 32 + k]++;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* true for those associated with some refs and belong
|
|
|
|
* in "ours" list aka "step 7 not done yet"
|
|
|
|
*/
|
|
|
|
si->need_reachability_test[i] =
|
|
|
|
si->need_reachability_test[i] > 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* keep hooks happy by forcing a temporary shallow file via
|
|
|
|
* env variable because we can't add --shallow-file to every
|
2018-09-21 23:04:45 +00:00
|
|
|
* command. check_connected() will be done with
|
2013-12-05 13:02:47 +00:00
|
|
|
* true .git/shallow though.
|
|
|
|
*/
|
|
|
|
setenv(GIT_SHALLOW_FILE_ENVIRONMENT, alt_shallow_file, 1);
|
|
|
|
}
|
|
|
|
|
2013-12-05 13:02:44 +00:00
|
|
|
static void update_shallow_info(struct command *commands,
|
|
|
|
struct shallow_info *si,
|
2017-03-31 01:40:00 +00:00
|
|
|
struct oid_array *ref)
|
2013-12-05 13:02:44 +00:00
|
|
|
{
|
|
|
|
struct command *cmd;
|
|
|
|
int *ref_status;
|
|
|
|
remove_nonexistent_theirs_shallow(si);
|
2013-12-05 13:02:47 +00:00
|
|
|
if (!si->nr_ours && !si->nr_theirs) {
|
|
|
|
shallow_update = 0;
|
2013-12-05 13:02:44 +00:00
|
|
|
return;
|
2013-12-05 13:02:47 +00:00
|
|
|
}
|
2013-12-05 13:02:44 +00:00
|
|
|
|
|
|
|
for (cmd = commands; cmd; cmd = cmd->next) {
|
2017-03-26 16:01:29 +00:00
|
|
|
if (is_null_oid(&cmd->new_oid))
|
2013-12-05 13:02:44 +00:00
|
|
|
continue;
|
2017-03-31 01:40:00 +00:00
|
|
|
oid_array_append(ref, &cmd->new_oid);
|
2013-12-05 13:02:44 +00:00
|
|
|
cmd->index = ref->nr - 1;
|
|
|
|
}
|
|
|
|
si->ref = ref;
|
|
|
|
|
2013-12-05 13:02:47 +00:00
|
|
|
if (shallow_update) {
|
2019-05-09 21:31:39 +00:00
|
|
|
prepare_shallow_update(si);
|
2013-12-05 13:02:47 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-02-22 22:44:25 +00:00
|
|
|
ALLOC_ARRAY(ref_status, ref->nr);
|
2013-12-05 13:02:44 +00:00
|
|
|
assign_shallow_commits_to_refs(si, NULL, ref_status);
|
|
|
|
for (cmd = commands; cmd; cmd = cmd->next) {
|
2017-03-26 16:01:29 +00:00
|
|
|
if (is_null_oid(&cmd->new_oid))
|
2013-12-05 13:02:44 +00:00
|
|
|
continue;
|
|
|
|
if (ref_status[cmd->index]) {
|
|
|
|
cmd->error_string = "shallow update not allowed";
|
|
|
|
cmd->skip_update = 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
free(ref_status);
|
|
|
|
}
|
|
|
|
|
2010-04-19 22:08:30 +00:00
|
|
|
static void report(struct command *commands, const char *unpack_status)
|
2005-12-26 07:18:37 +00:00
|
|
|
{
|
|
|
|
struct command *cmd;
|
2010-02-05 20:57:41 +00:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
|
|
|
packet_buf_write(&buf, "unpack %s\n",
|
|
|
|
unpack_status ? unpack_status : "ok");
|
2005-12-26 07:18:37 +00:00
|
|
|
for (cmd = commands; cmd; cmd = cmd->next) {
|
|
|
|
if (!cmd->error_string)
|
2010-02-05 20:57:41 +00:00
|
|
|
packet_buf_write(&buf, "ok %s\n",
|
|
|
|
cmd->ref_name);
|
2005-12-26 07:18:37 +00:00
|
|
|
else
|
2010-02-05 20:57:41 +00:00
|
|
|
packet_buf_write(&buf, "ng %s %s\n",
|
|
|
|
cmd->ref_name, cmd->error_string);
|
2005-06-30 00:52:11 +00:00
|
|
|
}
|
2010-02-05 20:57:41 +00:00
|
|
|
packet_buf_flush(&buf);
|
|
|
|
|
|
|
|
if (use_sideband)
|
|
|
|
send_sideband(1, 1, buf.buf, buf.len, use_sideband);
|
|
|
|
else
|
2013-02-20 20:01:56 +00:00
|
|
|
write_or_die(1, buf.buf, buf.len);
|
2010-02-05 20:57:41 +00:00
|
|
|
strbuf_release(&buf);
|
2005-06-30 00:52:11 +00:00
|
|
|
}
|
|
|
|
|
2020-08-27 15:45:46 +00:00
|
|
|
static void report_v2(struct command *commands, const char *unpack_status)
|
|
|
|
{
|
|
|
|
struct command *cmd;
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
struct ref_push_report *report;
|
|
|
|
|
|
|
|
packet_buf_write(&buf, "unpack %s\n",
|
|
|
|
unpack_status ? unpack_status : "ok");
|
|
|
|
for (cmd = commands; cmd; cmd = cmd->next) {
|
|
|
|
int count = 0;
|
|
|
|
|
|
|
|
if (cmd->error_string) {
|
|
|
|
packet_buf_write(&buf, "ng %s %s\n",
|
|
|
|
cmd->ref_name,
|
|
|
|
cmd->error_string);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
packet_buf_write(&buf, "ok %s\n",
|
|
|
|
cmd->ref_name);
|
|
|
|
for (report = cmd->report; report; report = report->next) {
|
|
|
|
if (count++ > 0)
|
|
|
|
packet_buf_write(&buf, "ok %s\n",
|
|
|
|
cmd->ref_name);
|
|
|
|
if (report->ref_name)
|
|
|
|
packet_buf_write(&buf, "option refname %s\n",
|
|
|
|
report->ref_name);
|
|
|
|
if (report->old_oid)
|
|
|
|
packet_buf_write(&buf, "option old-oid %s\n",
|
|
|
|
oid_to_hex(report->old_oid));
|
|
|
|
if (report->new_oid)
|
|
|
|
packet_buf_write(&buf, "option new-oid %s\n",
|
|
|
|
oid_to_hex(report->new_oid));
|
|
|
|
if (report->forced_update)
|
|
|
|
packet_buf_write(&buf, "option forced-update\n");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
packet_buf_flush(&buf);
|
|
|
|
|
|
|
|
if (use_sideband)
|
|
|
|
send_sideband(1, 1, buf.buf, buf.len, use_sideband);
|
|
|
|
else
|
|
|
|
write_or_die(1, buf.buf, buf.len);
|
|
|
|
strbuf_release(&buf);
|
|
|
|
}
|
|
|
|
|
2010-04-19 22:08:30 +00:00
|
|
|
static int delete_only(struct command *commands)
|
2006-11-24 08:26:49 +00:00
|
|
|
{
|
2010-04-19 22:08:30 +00:00
|
|
|
struct command *cmd;
|
|
|
|
for (cmd = commands; cmd; cmd = cmd->next) {
|
2017-03-26 16:01:29 +00:00
|
|
|
if (!is_null_oid(&cmd->new_oid))
|
2006-11-24 08:26:49 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2008-09-09 08:27:08 +00:00
|
|
|
int cmd_receive_pack(int argc, const char **argv, const char *prefix)
|
2005-06-30 00:52:11 +00:00
|
|
|
{
|
2009-10-31 00:47:33 +00:00
|
|
|
int advertise_refs = 0;
|
2010-04-19 22:08:30 +00:00
|
|
|
struct command *commands;
|
2017-03-31 01:40:00 +00:00
|
|
|
struct oid_array shallow = OID_ARRAY_INIT;
|
|
|
|
struct oid_array ref = OID_ARRAY_INIT;
|
2013-12-05 13:02:44 +00:00
|
|
|
struct shallow_info si;
|
2018-12-29 21:19:14 +00:00
|
|
|
struct packet_reader reader;
|
2005-06-30 00:52:11 +00:00
|
|
|
|
2016-03-01 20:21:01 +00:00
|
|
|
struct option options[] = {
|
|
|
|
OPT__QUIET(&quiet, N_("quiet")),
|
|
|
|
OPT_HIDDEN_BOOL(0, "stateless-rpc", &stateless_rpc, NULL),
|
2021-08-05 01:25:43 +00:00
|
|
|
OPT_HIDDEN_BOOL(0, "http-backend-info-refs", &advertise_refs, NULL),
|
|
|
|
OPT_ALIAS(0, "advertise-refs", "http-backend-info-refs"),
|
2016-03-01 20:21:01 +00:00
|
|
|
OPT_HIDDEN_BOOL(0, "reject-thin-pack-for-testing", &reject_thin, NULL),
|
|
|
|
OPT_END()
|
|
|
|
};
|
2011-02-24 14:30:19 +00:00
|
|
|
|
2016-03-01 20:21:01 +00:00
|
|
|
packet_trace_identity("receive-pack");
|
2005-06-30 00:52:11 +00:00
|
|
|
|
2016-03-01 20:21:01 +00:00
|
|
|
argc = parse_options(argc, argv, prefix, options, receive_pack_usage, 0);
|
2012-01-08 21:06:20 +00:00
|
|
|
|
2016-03-01 20:21:01 +00:00
|
|
|
if (argc > 1)
|
2021-12-01 22:15:41 +00:00
|
|
|
usage_msg_opt(_("too many arguments"), receive_pack_usage, options);
|
2016-03-01 20:21:01 +00:00
|
|
|
if (argc == 0)
|
2021-12-01 22:15:41 +00:00
|
|
|
usage_msg_opt(_("you must specify a directory"), receive_pack_usage, options);
|
2009-10-31 00:47:33 +00:00
|
|
|
|
2016-03-01 20:21:01 +00:00
|
|
|
service_dir = argv[0];
|
2005-06-30 00:52:11 +00:00
|
|
|
|
2008-07-21 19:19:52 +00:00
|
|
|
setup_path();
|
2008-03-03 04:08:43 +00:00
|
|
|
|
signed push: allow stale nonce in stateless mode
When operating with the stateless RPC mode, we will receive a nonce
issued by another instance of us that advertised our capability and
refs some time ago. Update the logic to check received nonce to
detect this case, compute how much time has passed since the nonce
was issued and report the status with a new environment variable
GIT_PUSH_CERT_NONCE_SLOP to the hooks.
GIT_PUSH_CERT_NONCE_STATUS will report "SLOP" in such a case. The
hooks are free to decide how large a slop it is willing to accept.
Strictly speaking, the "nonce" is not really a "nonce" anymore in
the stateless RPC mode, as it will happily take any "nonce" issued
by it (which is protected by HMAC and its secret key) as long as it
is fresh enough. The degree of this security degradation, relative
to the native protocol, is about the same as the "we make sure that
the 'git push' decided to update our refs with new objects based on
the freshest observation of our refs by making sure the values they
claim the original value of the refs they ask us to update exactly
match the current state" security is loosened to accomodate the
stateless RPC mode in the existing code without this series, so
there is no need for those who are already using smart HTTP to push
to their repositories to be alarmed any more than they already are.
In addition, the server operator can set receive.certnonceslop
configuration variable to specify how stale a nonce can be (in
seconds). When this variable is set, and if the nonce received in
the certificate that passes the HMAC check was less than that many
seconds old, hooks are given "OK" in GIT_PUSH_CERT_NONCE_STATUS
(instead of "SLOP") and the received nonce value is given in
GIT_PUSH_CERT_NONCE, which makes it easier for a simple-minded
hook to check if the certificate we received is recent enough.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-05 17:46:04 +00:00
|
|
|
if (!enter_repo(service_dir, 0))
|
|
|
|
die("'%s' does not appear to be a git repository", service_dir);
|
2005-06-30 00:52:11 +00:00
|
|
|
|
2008-05-14 17:46:53 +00:00
|
|
|
git_config(receive_pack_config, NULL);
|
2014-08-21 23:45:30 +00:00
|
|
|
if (cert_nonce_seed)
|
signed push: allow stale nonce in stateless mode
When operating with the stateless RPC mode, we will receive a nonce
issued by another instance of us that advertised our capability and
refs some time ago. Update the logic to check received nonce to
detect this case, compute how much time has passed since the nonce
was issued and report the status with a new environment variable
GIT_PUSH_CERT_NONCE_SLOP to the hooks.
GIT_PUSH_CERT_NONCE_STATUS will report "SLOP" in such a case. The
hooks are free to decide how large a slop it is willing to accept.
Strictly speaking, the "nonce" is not really a "nonce" anymore in
the stateless RPC mode, as it will happily take any "nonce" issued
by it (which is protected by HMAC and its secret key) as long as it
is fresh enough. The degree of this security degradation, relative
to the native protocol, is about the same as the "we make sure that
the 'git push' decided to update our refs with new objects based on
the freshest observation of our refs by making sure the values they
claim the original value of the refs they ask us to update exactly
match the current state" security is loosened to accomodate the
stateless RPC mode in the existing code without this series, so
there is no need for those who are already using smart HTTP to push
to their repositories to be alarmed any more than they already are.
In addition, the server operator can set receive.certnonceslop
configuration variable to specify how stale a nonce can be (in
seconds). When this variable is set, and if the nonce received in
the certificate that passes the HMAC check was less than that many
seconds old, hooks are given "OK" in GIT_PUSH_CERT_NONCE_STATUS
(instead of "SLOP") and the received nonce value is given in
GIT_PUSH_CERT_NONCE, which makes it easier for a simple-minded
hook to check if the certificate we received is recent enough.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-05 17:46:04 +00:00
|
|
|
push_cert_nonce = prepare_push_cert_nonce(service_dir, time(NULL));
|
2006-10-30 22:35:18 +00:00
|
|
|
|
2007-01-25 01:02:15 +00:00
|
|
|
if (0 <= transfer_unpack_limit)
|
|
|
|
unpack_limit = transfer_unpack_limit;
|
|
|
|
else if (0 <= receive_unpack_limit)
|
|
|
|
unpack_limit = receive_unpack_limit;
|
|
|
|
|
2017-10-16 17:55:26 +00:00
|
|
|
switch (determine_protocol_version_server()) {
|
2018-03-14 18:31:47 +00:00
|
|
|
case protocol_v2:
|
|
|
|
/*
|
|
|
|
* push support for protocol v2 has not been implemented yet,
|
|
|
|
* so ignore the request to use v2 and fallback to using v0.
|
|
|
|
*/
|
|
|
|
break;
|
2017-10-16 17:55:26 +00:00
|
|
|
case protocol_v1:
|
|
|
|
/*
|
|
|
|
* v1 is just the original protocol with a version string,
|
|
|
|
* so just fall through after writing the version string.
|
|
|
|
*/
|
|
|
|
if (advertise_refs || !stateless_rpc)
|
|
|
|
packet_write_fmt(1, "version 1\n");
|
|
|
|
|
|
|
|
/* fallthrough */
|
|
|
|
case protocol_v0:
|
|
|
|
break;
|
|
|
|
case protocol_unknown_version:
|
|
|
|
BUG("unknown protocol version");
|
|
|
|
}
|
|
|
|
|
2009-10-31 00:47:33 +00:00
|
|
|
if (advertise_refs || !stateless_rpc) {
|
|
|
|
write_head_info();
|
|
|
|
}
|
|
|
|
if (advertise_refs)
|
|
|
|
return 0;
|
2005-06-30 00:52:11 +00:00
|
|
|
|
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-29 21:19:15 +00:00
|
|
|
packet_reader_init(&reader, 0, NULL, 0,
|
|
|
|
PACKET_READ_CHOMP_NEWLINE |
|
|
|
|
PACKET_READ_DIE_ON_ERR_PACKET);
|
2018-12-29 21:19:14 +00:00
|
|
|
|
2022-05-02 16:50:37 +00:00
|
|
|
if ((commands = read_head_info(&reader, &shallow))) {
|
2006-11-24 08:26:49 +00:00
|
|
|
const char *unpack_status = NULL;
|
push options: {pre,post}-receive hook learns about push options
The environment variable GIT_PUSH_OPTION_COUNT is set to the number of
push options sent, and GIT_PUSH_OPTION_{0,1,..} is set to the transmitted
option.
The code is not executed as the push options are set to NULL, nor is the
new capability advertised.
There was some discussion back and forth how to present these push options
to the user as there are some ways to do it:
Keep all options in one environment variable
============================================
+ easiest way to implement in Git
- This would make things hard to parse correctly in the hook.
Put the options in files instead,
filenames are in GIT_PUSH_OPTION_FILES
======================================
+ After a discussion about environment variables and shells, we may not
want to put user data into an environment variable (see [1] for example).
+ We could transmit binaries, i.e. we're not bound to C strings as
we are when using environment variables to the user.
+ Maybe easier to parse than constructing environment variable names
GIT_PUSH_OPTION_{0,1,..} yourself
- cleanup of the temporary files is hard to do reliably
- we have race conditions with multiple clients pushing, hence we'd need
to use mkstemp. That's not too bad, but still.
Use environment variables, but restrict to key/value pairs
==========================================================
(When the user pushes a push option `foo=bar`, we'd
GIT_PUSH_OPTION_foo=bar)
+ very easy to parse for a simple model of push options
- it's not sufficient for more elaborate models, e.g.
it doesn't allow doubles (e.g. cc=reviewer@email)
Present the options in different environment variables
======================================================
(This is implemented)
* harder to parse as a user, but we have a sample hook for that.
- doesn't allow binary files
+ allows the same option twice, i.e. is not restrictive about
options, except for binary files.
+ doesn't clutter a remote directory with (possibly stale)
temporary files
As we first want to focus on getting simple strings to work
reliably, we go with the last option for now. If we want to
do transmission of binaries later, we can just attach a
'side-channel', e.g. "any push option that contains a '\0' is
put into a file instead of the environment variable and we'd
have new GIT_PUSH_OPTION_FILES, GIT_PUSH_OPTION_FILENAME_{0,1,..}
environment variables".
[1] 'Shellshock' https://lwn.net/Articles/614218/
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-14 21:49:45 +00:00
|
|
|
struct string_list push_options = STRING_LIST_INIT_DUP;
|
2006-11-24 08:26:49 +00:00
|
|
|
|
2016-07-14 21:49:46 +00:00
|
|
|
if (use_push_options)
|
2018-12-29 21:19:14 +00:00
|
|
|
read_push_options(&reader, &push_options);
|
2017-05-09 19:23:53 +00:00
|
|
|
if (!check_cert_push_options(&push_options)) {
|
|
|
|
struct command *cmd;
|
|
|
|
for (cmd = commands; cmd; cmd = cmd->next)
|
|
|
|
cmd->error_string = "inconsistent push options";
|
|
|
|
}
|
2016-07-14 21:49:46 +00:00
|
|
|
|
2013-12-05 13:02:44 +00:00
|
|
|
prepare_shallow_info(&si, &shallow);
|
2013-12-05 13:02:47 +00:00
|
|
|
if (!si.nr_ours && !si.nr_theirs)
|
|
|
|
shallow_update = 0;
|
2013-12-05 13:02:44 +00:00
|
|
|
if (!delete_only(commands)) {
|
|
|
|
unpack_status = unpack_with_sideband(&si);
|
|
|
|
update_shallow_info(commands, &si, &ref);
|
|
|
|
}
|
receive-pack: send keepalives during quiet periods
After a client has sent us the complete pack, we may spend
some time processing the data and running hooks. If the
client asked us to be quiet, receive-pack won't send any
progress data during the index-pack or connectivity-check
steps. And hooks may or may not produce their own progress
output. In these cases, the network connection is totally
silent from both ends.
Git itself doesn't care about this (it will wait forever),
but other parts of the system (e.g., firewalls,
load-balancers, etc) might hang up the connection. So we'd
like to send some sort of keepalive to let the network and
the client side know that we're still alive and processing.
We can use the same trick we did in 05e9515 (upload-pack:
send keepalive packets during pack computation, 2013-09-08).
Namely, we will send an empty sideband data packet every `N`
seconds that we do not relay any stderr data over the
sideband channel. As with 05e9515, this means that we won't
bother sending keepalives when there's actual progress data,
but will kick in when it has been disabled (or if there is a
lull in the progress data).
The concept is simple, but the details are subtle enough
that they need discussing here.
Before the client sends us the pack, we don't want to do any
keepalives. We'll have sent our ref advertisement, and we're
waiting for them to send us the pack (and tell us that they
support sidebands at all).
While we're receiving the pack from the client (or waiting
for it to start), there's no need for keepalives; it's up to
them to keep the connection active by sending data.
Moreover, it would be wrong for us to do so. When we are the
server in the smart-http protocol, we must treat our
connection as half-duplex. So any keepalives we send while
receiving the pack would potentially be buffered by the
webserver. Not only does this make them useless (since they
would not be delivered in a timely manner), but it could
actually cause a deadlock if we fill up the buffer with
keepalives. (It wouldn't be wrong to send keepalives in this
phase for a full-duplex connection like ssh; it's simply
pointless, as it is the client's responsibility to speak).
As soon as we've gotten all of the pack data, then the
client is waiting for us to speak, and we should start
keepalives immediately. From here until the end of the
connection, we send one any time we are not otherwise
sending data.
But there's a catch. Receive-pack doesn't know the moment
we've gotten all the data. It passes the descriptor to
index-pack, who reads all of the data, and then starts
resolving the deltas. We have to communicate that back.
To make this work, we instruct the sideband muxer to enable
keepalives in three phases:
1. In the beginning, not at all.
2. While reading from index-pack, wait for a signal
indicating end-of-input, and then start them.
3. Afterwards, always.
The signal from index-pack in phase 2 has to come over the
stderr channel which the muxer is reading. We can't use an
extra pipe because the portable run-command interface only
gives us stderr and stdout.
Stdout is already used to pass the .keep filename back to
receive-pack. We could also send a signal there, but then we
would find out about it in the main thread. And the
keepalive needs to be done by the async muxer thread (since
it's the one writing sideband data back to the client). And
we can't reliably signal the async thread from the main
thread, because the async code sometimes uses threads and
sometimes uses forked processes.
Therefore the signal must come over the stderr channel,
where it may be interspersed with other random
human-readable messages from index-pack. This patch makes
the signal a single NUL byte. This is easy to parse, should
not appear in any normal stderr output, and we don't have to
worry about any timing issues (like seeing half the signal
bytes in one read(), and half in a subsequent one).
This is a bit ugly, but it's simple to code and should work
reliably.
Another option would be to stop using an async thread for
muxing entirely, and just poll() both stderr and stdout of
index-pack from the main thread. This would work for
index-pack (because we aren't doing anything useful in the
main thread while it runs anyway). But it would make the
connectivity check and the hook muxers much more
complicated, as they need to simultaneously feed the
sub-programs while reading their stderr.
The index-pack phase is the only one that needs this
signaling, so it could simply behave differently than the
other two. That would mean having two separate
implementations of copy_to_sideband (and the keepalive
code), though. And it still doesn't get rid of the
signaling; it just means we can write a nicer message like
"END_OF_INPUT" or something on stdout, since we don't have
to worry about separating it from the stderr cruft.
One final note: this signaling trick is only done with
index-pack, not with unpack-objects. There's no point in
doing it for the latter, because by definition it only kicks
in for a small number of objects, where keepalives are not
as useful (and this conveniently lets us avoid duplicating
the implementation).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-15 10:43:47 +00:00
|
|
|
use_keepalive = KEEPALIVE_ALWAYS;
|
push options: {pre,post}-receive hook learns about push options
The environment variable GIT_PUSH_OPTION_COUNT is set to the number of
push options sent, and GIT_PUSH_OPTION_{0,1,..} is set to the transmitted
option.
The code is not executed as the push options are set to NULL, nor is the
new capability advertised.
There was some discussion back and forth how to present these push options
to the user as there are some ways to do it:
Keep all options in one environment variable
============================================
+ easiest way to implement in Git
- This would make things hard to parse correctly in the hook.
Put the options in files instead,
filenames are in GIT_PUSH_OPTION_FILES
======================================
+ After a discussion about environment variables and shells, we may not
want to put user data into an environment variable (see [1] for example).
+ We could transmit binaries, i.e. we're not bound to C strings as
we are when using environment variables to the user.
+ Maybe easier to parse than constructing environment variable names
GIT_PUSH_OPTION_{0,1,..} yourself
- cleanup of the temporary files is hard to do reliably
- we have race conditions with multiple clients pushing, hence we'd need
to use mkstemp. That's not too bad, but still.
Use environment variables, but restrict to key/value pairs
==========================================================
(When the user pushes a push option `foo=bar`, we'd
GIT_PUSH_OPTION_foo=bar)
+ very easy to parse for a simple model of push options
- it's not sufficient for more elaborate models, e.g.
it doesn't allow doubles (e.g. cc=reviewer@email)
Present the options in different environment variables
======================================================
(This is implemented)
* harder to parse as a user, but we have a sample hook for that.
- doesn't allow binary files
+ allows the same option twice, i.e. is not restrictive about
options, except for binary files.
+ doesn't clutter a remote directory with (possibly stale)
temporary files
As we first want to focus on getting simple strings to work
reliably, we go with the last option for now. If we want to
do transmission of binaries later, we can just attach a
'side-channel', e.g. "any push option that contains a '\0' is
put into a file instead of the environment variable and we'd
have new GIT_PUSH_OPTION_FILES, GIT_PUSH_OPTION_FILENAME_{0,1,..}
environment variables".
[1] 'Shellshock' https://lwn.net/Articles/614218/
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-14 21:49:45 +00:00
|
|
|
execute_commands(commands, unpack_status, &si,
|
|
|
|
&push_options);
|
2023-03-10 06:52:10 +00:00
|
|
|
delete_tempfile(&pack_lockfile);
|
2021-11-10 09:29:42 +00:00
|
|
|
sigchain_push(SIGPIPE, SIG_IGN);
|
2020-08-27 15:45:46 +00:00
|
|
|
if (report_status_v2)
|
|
|
|
report_v2(commands, unpack_status);
|
|
|
|
else if (report_status)
|
2010-04-19 22:08:30 +00:00
|
|
|
report(commands, unpack_status);
|
2021-11-10 09:29:42 +00:00
|
|
|
sigchain_pop(SIGPIPE);
|
push options: {pre,post}-receive hook learns about push options
The environment variable GIT_PUSH_OPTION_COUNT is set to the number of
push options sent, and GIT_PUSH_OPTION_{0,1,..} is set to the transmitted
option.
The code is not executed as the push options are set to NULL, nor is the
new capability advertised.
There was some discussion back and forth how to present these push options
to the user as there are some ways to do it:
Keep all options in one environment variable
============================================
+ easiest way to implement in Git
- This would make things hard to parse correctly in the hook.
Put the options in files instead,
filenames are in GIT_PUSH_OPTION_FILES
======================================
+ After a discussion about environment variables and shells, we may not
want to put user data into an environment variable (see [1] for example).
+ We could transmit binaries, i.e. we're not bound to C strings as
we are when using environment variables to the user.
+ Maybe easier to parse than constructing environment variable names
GIT_PUSH_OPTION_{0,1,..} yourself
- cleanup of the temporary files is hard to do reliably
- we have race conditions with multiple clients pushing, hence we'd need
to use mkstemp. That's not too bad, but still.
Use environment variables, but restrict to key/value pairs
==========================================================
(When the user pushes a push option `foo=bar`, we'd
GIT_PUSH_OPTION_foo=bar)
+ very easy to parse for a simple model of push options
- it's not sufficient for more elaborate models, e.g.
it doesn't allow doubles (e.g. cc=reviewer@email)
Present the options in different environment variables
======================================================
(This is implemented)
* harder to parse as a user, but we have a sample hook for that.
- doesn't allow binary files
+ allows the same option twice, i.e. is not restrictive about
options, except for binary files.
+ doesn't clutter a remote directory with (possibly stale)
temporary files
As we first want to focus on getting simple strings to work
reliably, we go with the last option for now. If we want to
do transmission of binaries later, we can just attach a
'side-channel', e.g. "any push option that contains a '\0' is
put into a file instead of the environment variable and we'd
have new GIT_PUSH_OPTION_FILES, GIT_PUSH_OPTION_FILENAME_{0,1,..}
environment variables".
[1] 'Shellshock' https://lwn.net/Articles/614218/
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-14 21:49:45 +00:00
|
|
|
run_receive_hook(commands, "post-receive", 1,
|
|
|
|
&push_options);
|
2007-03-07 21:50:24 +00:00
|
|
|
run_update_post_hook(commands);
|
2023-02-06 23:07:52 +00:00
|
|
|
free_commands(commands);
|
2017-01-29 13:09:46 +00:00
|
|
|
string_list_clear(&push_options, 0);
|
2009-10-20 21:56:40 +00:00
|
|
|
if (auto_gc) {
|
2016-06-05 09:36:38 +00:00
|
|
|
struct child_process proc = CHILD_PROCESS_INIT;
|
|
|
|
|
|
|
|
proc.no_stdin = 1;
|
|
|
|
proc.stdout_to_stderr = 1;
|
|
|
|
proc.err = use_sideband ? -1 : 0;
|
2021-09-09 09:47:08 +00:00
|
|
|
proc.git_cmd = proc.close_object_store = 1;
|
2021-11-25 22:52:20 +00:00
|
|
|
strvec_pushl(&proc.args, "gc", "--auto", "--quiet",
|
|
|
|
NULL);
|
2016-06-05 09:36:38 +00:00
|
|
|
|
|
|
|
if (!start_command(&proc)) {
|
|
|
|
if (use_sideband)
|
|
|
|
copy_to_sideband(proc.err, -1, NULL);
|
|
|
|
finish_command(&proc);
|
|
|
|
}
|
2009-10-20 21:56:40 +00:00
|
|
|
}
|
|
|
|
if (auto_update_server_info)
|
|
|
|
update_server_info(0);
|
2013-12-05 13:02:44 +00:00
|
|
|
clear_shallow_info(&si);
|
2005-06-30 05:50:48 +00:00
|
|
|
}
|
2010-02-05 20:57:41 +00:00
|
|
|
if (use_sideband)
|
|
|
|
packet_flush(1);
|
2017-03-31 01:40:00 +00:00
|
|
|
oid_array_clear(&shallow);
|
|
|
|
oid_array_clear(&ref);
|
2022-11-17 05:46:43 +00:00
|
|
|
string_list_clear(&hidden_refs, 0);
|
2014-08-21 23:45:30 +00:00
|
|
|
free((void *)push_cert_nonce);
|
2005-06-30 00:52:11 +00:00
|
|
|
return 0;
|
|
|
|
}
|