2011-04-03 09:06:54 +02:00
|
|
|
#include "builtin.h"
|
2014-10-01 12:28:42 +02:00
|
|
|
#include "lockfile.h"
|
2006-11-01 23:06:21 +01:00
|
|
|
#include "pack.h"
|
2005-07-03 05:23:36 +02:00
|
|
|
#include "refs.h"
|
2005-06-30 05:50:15 +02:00
|
|
|
#include "pkt-line.h"
|
2010-02-05 21:57:41 +01:00
|
|
|
#include "sideband.h"
|
2005-07-31 21:17:43 +02:00
|
|
|
#include "run-command.h"
|
2006-11-01 23:06:25 +01:00
|
|
|
#include "exec_cmd.h"
|
2006-09-21 01:07:54 +02: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 10:27:10 +02:00
|
|
|
#include "remote.h"
|
2013-07-08 22:56:53 +02:00
|
|
|
#include "connect.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 10:27:10 +02:00
|
|
|
#include "transport.h"
|
2010-04-20 00:19:18 +02:00
|
|
|
#include "string-list.h"
|
receive-pack: eliminate duplicate .have refs
When receiving a push, we advertise ref tips from any
alternate repositories, in case that helps the client send a
smaller pack. Since these refs don't actually exist in the
destination repository, we don't transmit the real ref
names, but instead use the pseudo-ref ".have".
If your alternate has a large number of duplicate refs (for
example, because it is aggregating objects from many related
repositories, some of which will have the same tags and
branch tips), then we will send each ".have $sha1" line
multiple times. This is a pointless waste of bandwidth, as
we are simply repeating the same fact to the client over and
over.
This patch eliminates duplicate .have refs early on. It does
so efficiently by sorting the complete list and skipping
duplicates. This has the side effect of re-ordering the
.have lines by ascending sha1; this isn't a problem, though,
as the original order was meaningless.
There is a similar .have system in fetch-pack, but it
does not suffer from the same problem. For each alternate
ref we consider in fetch-pack, we actually open the object
and mark it with the SEEN flag, so duplicates are
automatically culled.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-19 23:34:46 +02:00
|
|
|
#include "sha1-array.h"
|
2011-09-03 01:52:08 +02:00
|
|
|
#include "connected.h"
|
2013-12-05 14:02:43 +01:00
|
|
|
#include "argv-array.h"
|
2012-08-03 18:19:16 +02:00
|
|
|
#include "version.h"
|
2014-08-15 00:59:21 +02: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-13 00:48:07 +02:00
|
|
|
#include "sigchain.h"
|
2005-06-30 02:52:11 +02:00
|
|
|
|
2009-01-04 19:39:27 +01:00
|
|
|
static const char receive_pack_usage[] = "git receive-pack <git-dir>";
|
2005-06-30 02:52:11 +02:00
|
|
|
|
2008-11-09 02:49:27 +01:00
|
|
|
enum deny_action {
|
2009-02-01 02:34:05 +01:00
|
|
|
DENY_UNCONFIGURED,
|
2008-11-09 02:49:27 +01:00
|
|
|
DENY_IGNORE,
|
|
|
|
DENY_WARN,
|
2010-05-14 11:31:35 +02:00
|
|
|
DENY_REFUSE
|
2008-11-09 02:49:27 +01:00
|
|
|
};
|
|
|
|
|
2009-02-09 07:19:43 +01:00
|
|
|
static int deny_deletes;
|
|
|
|
static int deny_non_fast_forwards;
|
2009-02-01 02:34:05 +01:00
|
|
|
static enum deny_action deny_current_branch = DENY_UNCONFIGURED;
|
2009-02-09 07:31:21 +01:00
|
|
|
static enum deny_action deny_delete_current = DENY_UNCONFIGURED;
|
2011-09-04 21:37:45 +02:00
|
|
|
static int receive_fsck_objects = -1;
|
|
|
|
static int transfer_fsck_objects = -1;
|
2007-01-25 02:02:15 +01:00
|
|
|
static int receive_unpack_limit = -1;
|
|
|
|
static int transfer_unpack_limit = -1;
|
2006-12-07 05:01:00 +01:00
|
|
|
static int unpack_limit = 100;
|
2006-08-15 19:23:48 +02:00
|
|
|
static int report_status;
|
2010-02-05 21:57:41 +01:00
|
|
|
static int use_sideband;
|
2012-01-08 22:06:20 +01:00
|
|
|
static int quiet;
|
2009-05-01 22:56:47 +02:00
|
|
|
static int prefer_ofs_delta = 1;
|
2009-10-20 23:56:40 +02:00
|
|
|
static int auto_update_server_info;
|
|
|
|
static int auto_gc = 1;
|
2013-08-12 15:55:55 +02:00
|
|
|
static int fix_thin = 1;
|
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 19:46:04 +02:00
|
|
|
static int stateless_rpc;
|
|
|
|
static const char *service_dir;
|
2009-02-09 07:31:21 +01:00
|
|
|
static const char *head_name;
|
2011-12-13 15:17:48 +01:00
|
|
|
static void *head_name_to_free;
|
2010-02-05 21:57:40 +01:00
|
|
|
static int sent_capabilities;
|
2013-12-05 14:02:47 +01:00
|
|
|
static int shallow_update;
|
2013-12-05 14:02:44 +01: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 20:17:07 +02:00
|
|
|
static struct strbuf push_cert = STRBUF_INIT;
|
|
|
|
static unsigned char push_cert_sha1[20];
|
2014-08-15 00:59:21 +02:00
|
|
|
static struct signature_check sigcheck;
|
2014-08-22 01:45:30 +02:00
|
|
|
static const char *push_cert_nonce;
|
|
|
|
static const char *cert_nonce_seed;
|
|
|
|
|
|
|
|
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 19:46:04 +02:00
|
|
|
static const char *NONCE_SLOP = "SLOP";
|
2014-08-22 01:45:30 +02: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 19:46:04 +02:00
|
|
|
static long nonce_stamp_slop;
|
|
|
|
static unsigned long nonce_stamp_slop_limit;
|
2005-12-26 08:18:37 +01:00
|
|
|
|
2008-11-09 02:49:27 +01: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;
|
|
|
|
}
|
|
|
|
if (git_config_bool(var, value))
|
|
|
|
return DENY_REFUSE;
|
|
|
|
return DENY_IGNORE;
|
|
|
|
}
|
|
|
|
|
2008-05-14 19:46:53 +02:00
|
|
|
static int receive_pack_config(const char *var, const char *value, void *cb)
|
2006-10-30 23:35:18 +01: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 01:08:30 +01:00
|
|
|
int status = parse_hide_refs_config(var, value, "receive");
|
|
|
|
|
|
|
|
if (status)
|
|
|
|
return status;
|
|
|
|
|
2008-11-01 15:42:16 +01:00
|
|
|
if (strcmp(var, "receive.denydeletes") == 0) {
|
|
|
|
deny_deletes = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-01-25 02:02:15 +01:00
|
|
|
if (strcmp(var, "receive.denynonfastforwards") == 0) {
|
2006-10-30 23:35:18 +01:00
|
|
|
deny_non_fast_forwards = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-01-25 02:02:15 +01:00
|
|
|
if (strcmp(var, "receive.unpacklimit") == 0) {
|
|
|
|
receive_unpack_limit = git_config_int(var, value);
|
2006-11-01 23:06:21 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-01-25 02:02:15 +01:00
|
|
|
if (strcmp(var, "transfer.unpacklimit") == 0) {
|
|
|
|
transfer_unpack_limit = git_config_int(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-02-25 22:46:13 +01:00
|
|
|
if (strcmp(var, "receive.fsckobjects") == 0) {
|
|
|
|
receive_fsck_objects = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-09-04 21:37:45 +02:00
|
|
|
if (strcmp(var, "transfer.fsckobjects") == 0) {
|
|
|
|
transfer_fsck_objects = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-11-09 02:49:27 +01:00
|
|
|
if (!strcmp(var, "receive.denycurrentbranch")) {
|
|
|
|
deny_current_branch = parse_deny_action(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-02-09 07:31:21 +01:00
|
|
|
if (strcmp(var, "receive.denydeletecurrent") == 0) {
|
|
|
|
deny_delete_current = parse_deny_action(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-05-01 22:56:47 +02:00
|
|
|
if (strcmp(var, "repack.usedeltabaseoffset") == 0) {
|
|
|
|
prefer_ofs_delta = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-10-20 23:56:40 +02: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 14:02:47 +01:00
|
|
|
if (strcmp(var, "receive.shallowupdate") == 0) {
|
|
|
|
shallow_update = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-08-22 01:45:30 +02: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 20:17:07 +02: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 19:46:04 +02:00
|
|
|
if (strcmp(var, "receive.certnonceslop") == 0) {
|
|
|
|
nonce_stamp_slop_limit = git_config_ulong(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-05-14 19:46:53 +02:00
|
|
|
return git_default_config(var, value, cb);
|
2006-10-30 23:35:18 +01:00
|
|
|
}
|
|
|
|
|
2012-01-06 15:12:32 +01:00
|
|
|
static void show_ref(const char *path, const unsigned char *sha1)
|
2005-06-30 02:52:11 +02: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 01:08:30 +01:00
|
|
|
if (ref_is_hidden(path))
|
|
|
|
return;
|
|
|
|
|
2014-09-04 21:13:32 +02:00
|
|
|
if (sent_capabilities) {
|
2005-12-26 08:18:37 +01:00
|
|
|
packet_write(1, "%s %s\n", sha1_to_hex(sha1), path);
|
2014-09-04 21:13:32 +02:00
|
|
|
} else {
|
|
|
|
struct strbuf cap = STRBUF_INIT;
|
|
|
|
|
|
|
|
strbuf_addstr(&cap,
|
|
|
|
"report-status delete-refs side-band-64k quiet");
|
|
|
|
if (prefer_ofs_delta)
|
|
|
|
strbuf_addstr(&cap, " ofs-delta");
|
2014-08-22 01:45:30 +02:00
|
|
|
if (push_cert_nonce)
|
|
|
|
strbuf_addf(&cap, " push-cert=%s", push_cert_nonce);
|
2014-09-04 21:13:32 +02:00
|
|
|
strbuf_addf(&cap, " agent=%s", git_user_agent_sanitized());
|
|
|
|
packet_write(1, "%s %s%c%s\n",
|
|
|
|
sha1_to_hex(sha1), path, 0, cap.buf);
|
|
|
|
strbuf_release(&cap);
|
|
|
|
sent_capabilities = 1;
|
|
|
|
}
|
2005-06-30 02:52:11 +02:00
|
|
|
}
|
|
|
|
|
2012-01-06 15:12:32 +01:00
|
|
|
static int show_ref_cb(const char *path, const unsigned char *sha1, int flag, void *unused)
|
2011-07-09 01:13:32 +02:00
|
|
|
{
|
|
|
|
path = strip_namespace(path);
|
|
|
|
/*
|
|
|
|
* Advertise refs outside our current namespace as ".have"
|
|
|
|
* refs, so that the client can use them to minimize data
|
|
|
|
* transfer but will otherwise ignore them. This happens to
|
|
|
|
* cover ".have" that are thrown in by add_one_alternate_ref()
|
|
|
|
* to mark histories that are complete in our alternates as
|
|
|
|
* well.
|
|
|
|
*/
|
|
|
|
if (!path)
|
|
|
|
path = ".have";
|
2012-01-06 15:12:32 +01:00
|
|
|
show_ref(path, sha1);
|
|
|
|
return 0;
|
2011-07-09 01:13:32 +02:00
|
|
|
}
|
|
|
|
|
2012-01-06 15:12:33 +01:00
|
|
|
static void show_one_alternate_sha1(const unsigned char sha1[20], void *unused)
|
2012-01-06 15:12:31 +01:00
|
|
|
{
|
2012-01-06 15:12:33 +01:00
|
|
|
show_ref(".have", sha1);
|
2012-01-06 15:12:31 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
static void collect_one_alternate_ref(const struct ref *ref, void *data)
|
|
|
|
{
|
|
|
|
struct sha1_array *sa = data;
|
|
|
|
sha1_array_append(sa, ref->old_sha1);
|
2011-07-09 01:13:32 +02:00
|
|
|
}
|
|
|
|
|
2005-07-03 05:23:36 +02:00
|
|
|
static void write_head_info(void)
|
2005-06-30 02:52:11 +02:00
|
|
|
{
|
2012-01-06 15:12:31 +01:00
|
|
|
struct sha1_array sa = SHA1_ARRAY_INIT;
|
|
|
|
for_each_alternate_ref(collect_one_alternate_ref, &sa);
|
2012-01-06 15:12:33 +01:00
|
|
|
sha1_array_for_each_unique(&sa, show_one_alternate_sha1, NULL);
|
2012-01-06 15:12:31 +01:00
|
|
|
sha1_array_clear(&sa);
|
2011-07-09 01:13:32 +02:00
|
|
|
for_each_ref(show_ref_cb, NULL);
|
2010-02-05 21:57:40 +01:00
|
|
|
if (!sent_capabilities)
|
2012-01-06 15:12:32 +01:00
|
|
|
show_ref("capabilities^{}", null_sha1);
|
2005-12-26 08:18:37 +01:00
|
|
|
|
2013-12-05 14:02:32 +01:00
|
|
|
advertise_shallow_grafts(1);
|
|
|
|
|
2012-01-06 15:12:31 +01:00
|
|
|
/* EOF */
|
|
|
|
packet_flush(1);
|
2005-06-30 02:52:11 +02:00
|
|
|
}
|
|
|
|
|
2005-06-30 08:01:14 +02:00
|
|
|
struct command {
|
|
|
|
struct command *next;
|
2005-12-26 08:18:37 +01:00
|
|
|
const char *error_string;
|
2011-09-28 17:39:35 +02:00
|
|
|
unsigned int skip_update:1,
|
|
|
|
did_not_exist:1;
|
2013-12-05 14:02:44 +01:00
|
|
|
int index;
|
2005-06-30 08:01:14 +02:00
|
|
|
unsigned char old_sha1[20];
|
|
|
|
unsigned char new_sha1[20];
|
2006-01-07 10:33:54 +01:00
|
|
|
char ref_name[FLEX_ARRAY]; /* more */
|
2005-06-30 02:52:11 +02:00
|
|
|
};
|
|
|
|
|
2010-02-10 18:34:12 +01:00
|
|
|
static void rp_error(const char *err, ...) __attribute__((format (printf, 1, 2)));
|
|
|
|
static void rp_warning(const char *err, ...) __attribute__((format (printf, 1, 2)));
|
|
|
|
|
|
|
|
static void report_message(const char *prefix, const char *err, va_list params)
|
|
|
|
{
|
|
|
|
int sz = strlen(prefix);
|
|
|
|
char msg[4096];
|
|
|
|
|
|
|
|
strncpy(msg, prefix, sz);
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void rp_warning(const char *err, ...)
|
|
|
|
{
|
|
|
|
va_list params;
|
|
|
|
va_start(params, err);
|
|
|
|
report_message("warning: ", err, params);
|
|
|
|
va_end(params);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void rp_error(const char *err, ...)
|
|
|
|
{
|
|
|
|
va_list params;
|
|
|
|
va_start(params, err);
|
|
|
|
report_message("error: ", err, params);
|
|
|
|
va_end(params);
|
|
|
|
}
|
|
|
|
|
2010-02-05 21:57:42 +01:00
|
|
|
static int copy_to_sideband(int in, int out, void *arg)
|
|
|
|
{
|
|
|
|
char data[128];
|
|
|
|
while (1) {
|
|
|
|
ssize_t sz = xread(in, data, sizeof(data));
|
|
|
|
if (sz <= 0)
|
|
|
|
break;
|
|
|
|
send_sideband(1, 2, data, sz, use_sideband);
|
|
|
|
}
|
|
|
|
close(in);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-08-22 01:45:30 +02:00
|
|
|
#define HMAC_BLOCK_SIZE 64
|
|
|
|
|
2014-09-25 17:02:20 +02:00
|
|
|
static void hmac_sha1(unsigned char *out,
|
2014-08-22 01:45:30 +02:00
|
|
|
const char *key_in, size_t key_len,
|
|
|
|
const char *text, size_t text_len)
|
|
|
|
{
|
|
|
|
unsigned char key[HMAC_BLOCK_SIZE];
|
|
|
|
unsigned char k_ipad[HMAC_BLOCK_SIZE];
|
|
|
|
unsigned char k_opad[HMAC_BLOCK_SIZE];
|
|
|
|
int i;
|
|
|
|
git_SHA_CTX ctx;
|
|
|
|
|
|
|
|
/* RFC 2104 2. (1) */
|
|
|
|
memset(key, '\0', HMAC_BLOCK_SIZE);
|
|
|
|
if (HMAC_BLOCK_SIZE < key_len) {
|
|
|
|
git_SHA1_Init(&ctx);
|
|
|
|
git_SHA1_Update(&ctx, key_in, key_len);
|
|
|
|
git_SHA1_Final(key, &ctx);
|
|
|
|
} 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) */
|
|
|
|
git_SHA1_Init(&ctx);
|
|
|
|
git_SHA1_Update(&ctx, k_ipad, sizeof(k_ipad));
|
|
|
|
git_SHA1_Update(&ctx, text, text_len);
|
|
|
|
git_SHA1_Final(out, &ctx);
|
|
|
|
|
|
|
|
/* RFC 2104 2. (6) & (7) */
|
|
|
|
git_SHA1_Init(&ctx);
|
|
|
|
git_SHA1_Update(&ctx, k_opad, sizeof(k_opad));
|
2014-09-25 17:02:20 +02:00
|
|
|
git_SHA1_Update(&ctx, out, 20);
|
2014-08-22 01:45:30 +02:00
|
|
|
git_SHA1_Final(out, &ctx);
|
|
|
|
}
|
|
|
|
|
|
|
|
static char *prepare_push_cert_nonce(const char *path, unsigned long stamp)
|
|
|
|
{
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
unsigned char sha1[20];
|
|
|
|
|
|
|
|
strbuf_addf(&buf, "%s:%lu", path, stamp);
|
|
|
|
hmac_sha1(sha1, buf.buf, buf.len, cert_nonce_seed, strlen(cert_nonce_seed));;
|
|
|
|
strbuf_release(&buf);
|
|
|
|
|
|
|
|
/* RFC 2104 5. HMAC-SHA1-80 */
|
|
|
|
strbuf_addf(&buf, "%lu-%.*s", stamp, 20, sha1_to_hex(sha1));
|
|
|
|
return strbuf_detach(&buf, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* NEEDSWORK: reuse find_commit_header() from jk/commit-author-parsing
|
|
|
|
* after dropping "_commit" from its name and possibly moving it out
|
|
|
|
* of commit.c
|
|
|
|
*/
|
|
|
|
static char *find_header(const char *msg, size_t len, const char *key)
|
|
|
|
{
|
|
|
|
int key_len = strlen(key);
|
|
|
|
const char *line = msg;
|
|
|
|
|
|
|
|
while (line && line < msg + len) {
|
|
|
|
const char *eol = strchrnul(line, '\n');
|
|
|
|
|
|
|
|
if ((msg + len <= eol) || line == eol)
|
|
|
|
return NULL;
|
|
|
|
if (line + key_len < eol &&
|
|
|
|
!memcmp(line, key, key_len) && line[key_len] == ' ') {
|
|
|
|
int offset = key_len + 1;
|
|
|
|
return xmemdupz(line + offset, (eol - line) - offset);
|
|
|
|
}
|
|
|
|
line = *eol ? eol + 1 : NULL;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const char *check_nonce(const char *buf, size_t len)
|
|
|
|
{
|
|
|
|
char *nonce = find_header(buf, len, "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 19:46:04 +02:00
|
|
|
unsigned long stamp, ostamp;
|
|
|
|
char *bohmac, *expect = NULL;
|
2014-08-22 01:45:30 +02:00
|
|
|
const char *retval = NONCE_BAD;
|
|
|
|
|
|
|
|
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 19:46:04 +02: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;
|
|
|
|
}
|
|
|
|
stamp = strtoul(nonce, &bohmac, 10);
|
|
|
|
if (bohmac == nonce || bohmac[0] != '-') {
|
|
|
|
retval = NONCE_BAD;
|
|
|
|
goto leave;
|
|
|
|
}
|
|
|
|
|
|
|
|
expect = prepare_push_cert_nonce(service_dir, stamp);
|
|
|
|
if (strcmp(expect, nonce)) {
|
|
|
|
/* 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.
|
|
|
|
*/
|
|
|
|
ostamp = strtoul(push_cert_nonce, NULL, 10);
|
|
|
|
nonce_stamp_slop = (long)ostamp - (long)stamp;
|
|
|
|
|
|
|
|
if (nonce_stamp_slop_limit &&
|
|
|
|
abs(nonce_stamp_slop) <= nonce_stamp_slop_limit) {
|
|
|
|
/*
|
|
|
|
* 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-22 01:45:30 +02: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 19:46:04 +02:00
|
|
|
free(expect);
|
2014-08-22 01:45:30 +02:00
|
|
|
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 20:17:07 +02:00
|
|
|
static void prepare_push_cert_sha1(struct child_process *proc)
|
|
|
|
{
|
|
|
|
static int already_done;
|
|
|
|
struct argv_array env = ARGV_ARRAY_INIT;
|
|
|
|
|
|
|
|
if (!push_cert.len)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (!already_done) {
|
2014-08-15 00:59:21 +02:00
|
|
|
struct strbuf gpg_output = STRBUF_INIT;
|
|
|
|
struct strbuf gpg_status = STRBUF_INIT;
|
|
|
|
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 20:17:07 +02:00
|
|
|
already_done = 1;
|
|
|
|
if (write_sha1_file(push_cert.buf, push_cert.len, "blob", push_cert_sha1))
|
|
|
|
hashclr(push_cert_sha1);
|
2014-08-15 00:59:21 +02:00
|
|
|
|
|
|
|
memset(&sigcheck, '\0', sizeof(sigcheck));
|
|
|
|
sigcheck.result = 'N';
|
|
|
|
|
|
|
|
bogs = parse_signature(push_cert.buf, push_cert.len);
|
|
|
|
if (verify_signed_buffer(push_cert.buf, bogs,
|
|
|
|
push_cert.buf + bogs, push_cert.len - bogs,
|
|
|
|
&gpg_output, &gpg_status) < 0) {
|
|
|
|
; /* error running gpg */
|
|
|
|
} else {
|
|
|
|
sigcheck.payload = push_cert.buf;
|
|
|
|
sigcheck.gpg_output = gpg_output.buf;
|
|
|
|
sigcheck.gpg_status = gpg_status.buf;
|
|
|
|
parse_gpg_output(&sigcheck);
|
|
|
|
}
|
|
|
|
|
|
|
|
strbuf_release(&gpg_output);
|
|
|
|
strbuf_release(&gpg_status);
|
2014-08-22 01:45:30 +02: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 20:17:07 +02:00
|
|
|
}
|
|
|
|
if (!is_null_sha1(push_cert_sha1)) {
|
|
|
|
argv_array_pushf(&env, "GIT_PUSH_CERT=%s", sha1_to_hex(push_cert_sha1));
|
2014-08-15 00:59:21 +02:00
|
|
|
argv_array_pushf(&env, "GIT_PUSH_CERT_SIGNER=%s",
|
|
|
|
sigcheck.signer ? sigcheck.signer : "");
|
|
|
|
argv_array_pushf(&env, "GIT_PUSH_CERT_KEY=%s",
|
|
|
|
sigcheck.key ? sigcheck.key : "");
|
|
|
|
argv_array_pushf(&env, "GIT_PUSH_CERT_STATUS=%c", sigcheck.result);
|
2014-08-22 01:45:30 +02:00
|
|
|
if (push_cert_nonce) {
|
|
|
|
argv_array_pushf(&env, "GIT_PUSH_CERT_NONCE=%s", push_cert_nonce);
|
|
|
|
argv_array_pushf(&env, "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 19:46:04 +02:00
|
|
|
if (nonce_status == NONCE_SLOP)
|
|
|
|
argv_array_pushf(&env, "GIT_PUSH_CERT_NONCE_SLOP=%ld",
|
|
|
|
nonce_stamp_slop);
|
2014-08-22 01:45:30 +02: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 20:17:07 +02:00
|
|
|
proc->env = env.argv;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-09-08 21:17:09 +02:00
|
|
|
typedef int (*feed_fn)(void *, const char **, size_t *);
|
|
|
|
static int run_and_feed_hook(const char *hook_name, feed_fn feed, void *feed_state)
|
2005-07-31 21:17:43 +02:00
|
|
|
{
|
2014-08-19 21:09:35 +02:00
|
|
|
struct child_process proc = CHILD_PROCESS_INIT;
|
2010-02-05 21:57:42 +01:00
|
|
|
struct async muxer;
|
2007-03-10 09:28:16 +01:00
|
|
|
const char *argv[2];
|
2011-09-08 21:17:09 +02:00
|
|
|
int code;
|
2005-07-31 21:17:43 +02:00
|
|
|
|
2013-01-13 06:17:02 +01:00
|
|
|
argv[0] = find_hook(hook_name);
|
|
|
|
if (!argv[0])
|
2005-07-31 21:17:43 +02:00
|
|
|
return 0;
|
2007-03-07 22:51:09 +01:00
|
|
|
|
2007-03-10 09:28:16 +01:00
|
|
|
argv[1] = NULL;
|
|
|
|
|
|
|
|
proc.argv = argv;
|
|
|
|
proc.in = -1;
|
|
|
|
proc.stdout_to_stderr = 1;
|
|
|
|
|
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 20:17:07 +02:00
|
|
|
prepare_push_cert_sha1(&proc);
|
|
|
|
|
2010-02-05 21:57:42 +01: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;
|
|
|
|
}
|
|
|
|
|
2007-03-10 09:28:16 +01:00
|
|
|
code = start_command(&proc);
|
2010-02-05 21:57:42 +01:00
|
|
|
if (code) {
|
|
|
|
if (use_sideband)
|
|
|
|
finish_async(&muxer);
|
2009-07-04 21:26:43 +02:00
|
|
|
return code;
|
2010-02-05 21:57:42 +01: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-13 00:48:07 +02:00
|
|
|
sigchain_push(SIGPIPE, SIG_IGN);
|
|
|
|
|
2011-09-08 21:17:09 +02:00
|
|
|
while (1) {
|
|
|
|
const char *buf;
|
|
|
|
size_t n;
|
|
|
|
if (feed(feed_state, &buf, &n))
|
|
|
|
break;
|
|
|
|
if (write_in_full(proc.in, buf, n) != n)
|
|
|
|
break;
|
2007-03-07 22:51:09 +01:00
|
|
|
}
|
2008-02-16 18:36:38 +01:00
|
|
|
close(proc.in);
|
2010-02-05 21:57:42 +01: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-13 00:48:07 +02:00
|
|
|
|
|
|
|
sigchain_pop(SIGPIPE);
|
|
|
|
|
2009-07-04 21:26:43 +02:00
|
|
|
return finish_command(&proc);
|
2005-07-31 21:17:43 +02:00
|
|
|
}
|
|
|
|
|
2011-09-08 21:17:09 +02:00
|
|
|
struct receive_hook_feed_state {
|
|
|
|
struct command *cmd;
|
2011-10-18 06:37:10 +02:00
|
|
|
int skip_broken;
|
2011-09-08 21:17:09 +02:00
|
|
|
struct strbuf buf;
|
|
|
|
};
|
|
|
|
|
|
|
|
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 06:37:10 +02:00
|
|
|
while (cmd &&
|
|
|
|
state->skip_broken && (cmd->error_string || cmd->did_not_exist))
|
2011-09-08 21:17:09 +02:00
|
|
|
cmd = cmd->next;
|
|
|
|
if (!cmd)
|
|
|
|
return -1; /* EOF */
|
|
|
|
strbuf_reset(&state->buf);
|
|
|
|
strbuf_addf(&state->buf, "%s %s %s\n",
|
|
|
|
sha1_to_hex(cmd->old_sha1), sha1_to_hex(cmd->new_sha1),
|
|
|
|
cmd->ref_name);
|
|
|
|
state->cmd = cmd->next;
|
|
|
|
if (bufp) {
|
|
|
|
*bufp = state->buf.buf;
|
|
|
|
*sizep = state->buf.len;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-10-18 06:37:10 +02:00
|
|
|
static int run_receive_hook(struct command *commands, const char *hook_name,
|
|
|
|
int skip_broken)
|
2011-09-08 21:17:09 +02:00
|
|
|
{
|
|
|
|
struct receive_hook_feed_state state;
|
|
|
|
int status;
|
|
|
|
|
|
|
|
strbuf_init(&state.buf, 0);
|
|
|
|
state.cmd = commands;
|
2011-10-18 06:37:10 +02:00
|
|
|
state.skip_broken = skip_broken;
|
2011-09-08 21:17:09 +02:00
|
|
|
if (feed_receive_hook(&state, NULL, NULL))
|
|
|
|
return 0;
|
|
|
|
state.cmd = commands;
|
|
|
|
status = run_and_feed_hook(hook_name, feed_receive_hook, &state);
|
|
|
|
strbuf_release(&state.buf);
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2007-03-10 09:28:13 +01:00
|
|
|
static int run_update_hook(struct command *cmd)
|
|
|
|
{
|
|
|
|
const char *argv[5];
|
2014-08-19 21:09:35 +02:00
|
|
|
struct child_process proc = CHILD_PROCESS_INIT;
|
2010-02-05 21:57:42 +01:00
|
|
|
int code;
|
2007-03-10 09:28:13 +01:00
|
|
|
|
2013-01-13 06:17:02 +01:00
|
|
|
argv[0] = find_hook("update");
|
|
|
|
if (!argv[0])
|
2007-03-10 09:28:13 +01:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
argv[1] = cmd->ref_name;
|
|
|
|
argv[2] = sha1_to_hex(cmd->old_sha1);
|
|
|
|
argv[3] = sha1_to_hex(cmd->new_sha1);
|
|
|
|
argv[4] = NULL;
|
|
|
|
|
2010-02-05 21:57:42 +01:00
|
|
|
proc.no_stdin = 1;
|
|
|
|
proc.stdout_to_stderr = 1;
|
|
|
|
proc.err = use_sideband ? -1 : 0;
|
|
|
|
proc.argv = argv;
|
|
|
|
|
|
|
|
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 09:28:13 +01:00
|
|
|
}
|
|
|
|
|
2008-11-09 02:49:27 +01:00
|
|
|
static int is_ref_checked_out(const char *ref)
|
|
|
|
{
|
|
|
|
if (is_bare_repository())
|
|
|
|
return 0;
|
|
|
|
|
2009-02-09 07:31:21 +01:00
|
|
|
if (!head_name)
|
2008-11-09 02:49:27 +01:00
|
|
|
return 0;
|
2009-02-09 07:31:21 +01:00
|
|
|
return !strcmp(head_name, ref);
|
2008-11-09 02:49:27 +01:00
|
|
|
}
|
|
|
|
|
2009-02-11 11:28:03 +01:00
|
|
|
static char *refuse_unconfigured_deny_msg[] = {
|
|
|
|
"By default, updating the current branch in a non-bare repository",
|
|
|
|
"is denied, because it will make the index and work tree inconsistent",
|
|
|
|
"with what you pushed, and will require 'git reset --hard' to match",
|
|
|
|
"the work tree to HEAD.",
|
2009-02-01 02:34:05 +01:00
|
|
|
"",
|
|
|
|
"You can set 'receive.denyCurrentBranch' configuration variable to",
|
2009-02-11 11:28:03 +01:00
|
|
|
"'ignore' or 'warn' in the remote repository to allow pushing into",
|
|
|
|
"its current branch; however, this is not recommended unless you",
|
|
|
|
"arranged to update its work tree to match what you pushed in some",
|
|
|
|
"other way.",
|
2009-02-01 02:34:05 +01:00
|
|
|
"",
|
2009-02-11 11:28:03 +01:00
|
|
|
"To squelch this message and still keep the default behaviour, set",
|
|
|
|
"'receive.denyCurrentBranch' configuration variable to 'refuse'."
|
2009-02-01 02:34:05 +01:00
|
|
|
};
|
|
|
|
|
2009-02-11 11:28:03 +01:00
|
|
|
static void refuse_unconfigured_deny(void)
|
2009-02-01 02:34:05 +01:00
|
|
|
{
|
|
|
|
int i;
|
2009-02-11 11:28:03 +01:00
|
|
|
for (i = 0; i < ARRAY_SIZE(refuse_unconfigured_deny_msg); i++)
|
2010-03-03 07:54:50 +01:00
|
|
|
rp_error("%s", refuse_unconfigured_deny_msg[i]);
|
2009-02-01 02:34:05 +01:00
|
|
|
}
|
|
|
|
|
2009-02-09 09:19:46 +01:00
|
|
|
static char *refuse_unconfigured_deny_delete_current_msg[] = {
|
|
|
|
"By default, deleting the current branch is denied, because the next",
|
|
|
|
"'git clone' won't result in any file checked out, causing confusion.",
|
2009-02-09 07:31:21 +01:00
|
|
|
"",
|
|
|
|
"You can set 'receive.denyDeleteCurrent' configuration variable to",
|
2009-02-09 09:19:46 +01:00
|
|
|
"'warn' or 'ignore' in the remote repository to allow deleting the",
|
|
|
|
"current branch, with or without a warning message.",
|
2009-02-09 07:31:21 +01:00
|
|
|
"",
|
2009-02-09 09:19:46 +01:00
|
|
|
"To squelch this message, you can set it to 'refuse'."
|
2009-02-09 07:31:21 +01:00
|
|
|
};
|
|
|
|
|
2009-02-09 09:19:46 +01:00
|
|
|
static void refuse_unconfigured_deny_delete_current(void)
|
2009-02-09 07:31:21 +01:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
for (i = 0;
|
2009-02-09 09:19:46 +01:00
|
|
|
i < ARRAY_SIZE(refuse_unconfigured_deny_delete_current_msg);
|
2009-02-09 07:31:21 +01:00
|
|
|
i++)
|
2010-03-03 07:54:50 +01:00
|
|
|
rp_error("%s", refuse_unconfigured_deny_delete_current_msg[i]);
|
2009-02-09 07:31:21 +01:00
|
|
|
}
|
|
|
|
|
2013-12-05 14:02:47 +01:00
|
|
|
static int command_singleton_iterator(void *cb_data, unsigned char sha1[20]);
|
|
|
|
static int update_shallow_ref(struct command *cmd, struct shallow_info *si)
|
|
|
|
{
|
|
|
|
static struct lock_file shallow_lock;
|
|
|
|
struct sha1_array extra = SHA1_ARRAY_INIT;
|
|
|
|
const char *alt_file;
|
|
|
|
uint32_t mask = 1 << (cmd->index % 32);
|
|
|
|
int i;
|
|
|
|
|
2014-07-12 02:00:06 +02:00
|
|
|
trace_printf_key(&trace_shallow,
|
2013-12-05 14:02:47 +01: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))
|
|
|
|
sha1_array_append(&extra, si->shallow->sha1[i]);
|
|
|
|
|
|
|
|
setup_alternate_shallow(&shallow_lock, &alt_file, &extra);
|
|
|
|
if (check_shallow_connected(command_singleton_iterator,
|
|
|
|
0, cmd, alt_file)) {
|
|
|
|
rollback_lock_file(&shallow_lock);
|
|
|
|
sha1_array_clear(&extra);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
commit_lock_file(&shallow_lock);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Make sure setup_alternate_shallow() for the next ref does
|
|
|
|
* not lose these new roots..
|
|
|
|
*/
|
|
|
|
for (i = 0; i < extra.nr; i++)
|
|
|
|
register_shallow(extra.sha1[i]);
|
|
|
|
|
|
|
|
si->shallow_ref[cmd->index] = 0;
|
|
|
|
sha1_array_clear(&extra);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const char *update(struct command *cmd, struct shallow_info *si)
|
2005-06-30 19:15:22 +02:00
|
|
|
{
|
2005-12-26 08:18:37 +01:00
|
|
|
const char *name = cmd->ref_name;
|
2011-07-09 01:13:32 +02:00
|
|
|
struct strbuf namespaced_name_buf = STRBUF_INIT;
|
|
|
|
const char *namespaced_name;
|
2005-12-26 08:18:37 +01:00
|
|
|
unsigned char *old_sha1 = cmd->old_sha1;
|
|
|
|
unsigned char *new_sha1 = cmd->new_sha1;
|
2005-06-30 19:15:22 +02:00
|
|
|
|
2008-01-04 20:37:17 +01:00
|
|
|
/* only refs/... are allowed */
|
2013-11-30 21:55:40 +01:00
|
|
|
if (!starts_with(name, "refs/") || check_refname_format(name + 5, 0)) {
|
2010-02-10 18:34:12 +01:00
|
|
|
rp_error("refusing to create funny ref '%s' remotely", name);
|
2007-03-07 22:51:59 +01:00
|
|
|
return "funny refname";
|
2005-12-26 08:18:37 +01:00
|
|
|
}
|
2005-10-14 03:57:39 +02:00
|
|
|
|
2011-07-09 01:13:32 +02:00
|
|
|
strbuf_addf(&namespaced_name_buf, "%s%s", get_git_namespace(), name);
|
|
|
|
namespaced_name = strbuf_detach(&namespaced_name_buf, NULL);
|
|
|
|
|
|
|
|
if (is_ref_checked_out(namespaced_name)) {
|
2009-02-01 02:34:05 +01:00
|
|
|
switch (deny_current_branch) {
|
|
|
|
case DENY_IGNORE:
|
2008-11-09 02:49:27 +01:00
|
|
|
break;
|
2009-02-01 02:34:05 +01:00
|
|
|
case DENY_WARN:
|
2010-02-10 18:34:12 +01:00
|
|
|
rp_warning("updating the current branch");
|
2008-11-09 02:49:27 +01:00
|
|
|
break;
|
2009-02-01 02:34:05 +01:00
|
|
|
case DENY_REFUSE:
|
2009-02-11 11:28:03 +01:00
|
|
|
case DENY_UNCONFIGURED:
|
2010-02-10 18:34:12 +01:00
|
|
|
rp_error("refusing to update checked out branch: %s", name);
|
2009-02-11 11:28:03 +01:00
|
|
|
if (deny_current_branch == DENY_UNCONFIGURED)
|
|
|
|
refuse_unconfigured_deny();
|
2009-02-01 02:34:05 +01:00
|
|
|
return "branch is currently checked out";
|
|
|
|
}
|
2008-11-09 02:49:27 +01:00
|
|
|
}
|
|
|
|
|
2006-11-24 09:26:49 +01:00
|
|
|
if (!is_null_sha1(new_sha1) && !has_sha1_file(new_sha1)) {
|
2007-03-07 22:51:59 +01:00
|
|
|
error("unpack should have generated %s, "
|
|
|
|
"but I can't find it!", sha1_to_hex(new_sha1));
|
|
|
|
return "bad pack";
|
2005-12-26 08:18:37 +01:00
|
|
|
}
|
2009-02-09 07:31:21 +01:00
|
|
|
|
|
|
|
if (!is_null_sha1(old_sha1) && is_null_sha1(new_sha1)) {
|
2013-11-30 21:55:40 +01:00
|
|
|
if (deny_deletes && starts_with(name, "refs/heads/")) {
|
2010-02-10 18:34:12 +01:00
|
|
|
rp_error("denying ref deletion for %s", name);
|
2009-02-09 07:31:21 +01:00
|
|
|
return "deletion prohibited";
|
|
|
|
}
|
|
|
|
|
2011-07-09 01:13:32 +02:00
|
|
|
if (!strcmp(namespaced_name, head_name)) {
|
2009-02-09 07:31:21 +01:00
|
|
|
switch (deny_delete_current) {
|
|
|
|
case DENY_IGNORE:
|
|
|
|
break;
|
|
|
|
case DENY_WARN:
|
2010-02-10 18:34:12 +01:00
|
|
|
rp_warning("deleting the current branch");
|
2009-02-09 07:31:21 +01:00
|
|
|
break;
|
|
|
|
case DENY_REFUSE:
|
2009-02-09 09:19:46 +01:00
|
|
|
case DENY_UNCONFIGURED:
|
|
|
|
if (deny_delete_current == DENY_UNCONFIGURED)
|
|
|
|
refuse_unconfigured_deny_delete_current();
|
2010-02-10 18:34:12 +01:00
|
|
|
rp_error("refusing to delete the current branch: %s", name);
|
2009-02-09 07:31:21 +01:00
|
|
|
return "deletion of the current branch prohibited";
|
|
|
|
}
|
|
|
|
}
|
2008-11-01 15:42:16 +01:00
|
|
|
}
|
2009-02-09 07:31:21 +01:00
|
|
|
|
2006-11-24 09:26:49 +01:00
|
|
|
if (deny_non_fast_forwards && !is_null_sha1(new_sha1) &&
|
2006-12-05 01:30:00 +01:00
|
|
|
!is_null_sha1(old_sha1) &&
|
2013-11-30 21:55:40 +01:00
|
|
|
starts_with(name, "refs/heads/")) {
|
2008-01-02 08:39:21 +01:00
|
|
|
struct object *old_object, *new_object;
|
2006-09-21 01:07:54 +02:00
|
|
|
struct commit *old_commit, *new_commit;
|
|
|
|
|
2008-01-02 08:39:21 +01:00
|
|
|
old_object = parse_object(old_sha1);
|
|
|
|
new_object = parse_object(new_sha1);
|
|
|
|
|
|
|
|
if (!old_object || !new_object ||
|
|
|
|
old_object->type != OBJ_COMMIT ||
|
|
|
|
new_object->type != OBJ_COMMIT) {
|
|
|
|
error("bad sha1 objects for %s", name);
|
|
|
|
return "bad ref";
|
|
|
|
}
|
|
|
|
old_commit = (struct commit *)old_object;
|
|
|
|
new_commit = (struct commit *)new_object;
|
2012-08-28 00:16:38 +02:00
|
|
|
if (!in_merge_bases(old_commit, new_commit)) {
|
2010-02-10 18:34:12 +01:00
|
|
|
rp_error("denying non-fast-forward %s"
|
|
|
|
" (you should pull first)", name);
|
2009-10-24 10:31:32 +02:00
|
|
|
return "non-fast-forward";
|
2007-03-07 22:51:59 +01:00
|
|
|
}
|
2006-09-21 01:07:54 +02:00
|
|
|
}
|
2007-03-10 09:28:13 +01:00
|
|
|
if (run_update_hook(cmd)) {
|
2010-02-10 18:34:12 +01:00
|
|
|
rp_error("hook declined to update %s", name);
|
2007-03-07 22:51:59 +01:00
|
|
|
return "hook declined";
|
2005-07-31 21:17:43 +02:00
|
|
|
}
|
2006-09-27 11:40:06 +02:00
|
|
|
|
2006-11-24 09:26:49 +01:00
|
|
|
if (is_null_sha1(new_sha1)) {
|
2007-11-29 02:02:53 +01:00
|
|
|
if (!parse_object(old_sha1)) {
|
|
|
|
old_sha1 = NULL;
|
2011-09-28 17:39:35 +02:00
|
|
|
if (ref_exists(name)) {
|
|
|
|
rp_warning("Allowing deletion of corrupt ref.");
|
|
|
|
} else {
|
|
|
|
rp_warning("Deleting a non-existent ref.");
|
|
|
|
cmd->did_not_exist = 1;
|
|
|
|
}
|
2007-11-29 02:02:53 +01:00
|
|
|
}
|
2011-07-09 01:13:32 +02:00
|
|
|
if (delete_ref(namespaced_name, old_sha1, 0)) {
|
2010-02-10 18:34:12 +01:00
|
|
|
rp_error("failed to delete %s", name);
|
2007-03-07 22:51:59 +01:00
|
|
|
return "failed to delete";
|
2006-11-24 09:26:49 +01:00
|
|
|
}
|
2007-03-07 22:51:59 +01:00
|
|
|
return NULL; /* good */
|
2006-11-24 09:26:49 +01:00
|
|
|
}
|
|
|
|
else {
|
2014-04-28 23:36:15 +02:00
|
|
|
struct strbuf err = STRBUF_INIT;
|
|
|
|
struct ref_transaction *transaction;
|
|
|
|
|
2013-12-05 14:02:47 +01:00
|
|
|
if (shallow_update && si->shallow_ref[cmd->index] &&
|
|
|
|
update_shallow_ref(cmd, si))
|
|
|
|
return "shallow error";
|
|
|
|
|
2014-04-28 23:36:15 +02:00
|
|
|
transaction = ref_transaction_begin(&err);
|
|
|
|
if (!transaction ||
|
|
|
|
ref_transaction_update(transaction, namespaced_name,
|
2014-04-30 21:22:42 +02:00
|
|
|
new_sha1, old_sha1, 0, 1, "push",
|
|
|
|
&err) ||
|
|
|
|
ref_transaction_commit(transaction, &err)) {
|
2014-04-28 23:36:15 +02:00
|
|
|
ref_transaction_free(transaction);
|
|
|
|
|
|
|
|
rp_error("%s", err.buf);
|
|
|
|
strbuf_release(&err);
|
|
|
|
return "failed to update ref";
|
2007-03-07 18:04:24 +01:00
|
|
|
}
|
2014-04-28 23:36:15 +02:00
|
|
|
|
|
|
|
ref_transaction_free(transaction);
|
|
|
|
strbuf_release(&err);
|
2007-03-07 22:51:59 +01:00
|
|
|
return NULL; /* good */
|
2005-08-02 23:24:22 +02:00
|
|
|
}
|
2005-06-30 19:15:22 +02:00
|
|
|
}
|
|
|
|
|
2010-04-20 00:08:30 +02:00
|
|
|
static void run_update_post_hook(struct command *commands)
|
2005-08-02 23:24:22 +02:00
|
|
|
{
|
2010-04-20 00:08:30 +02:00
|
|
|
struct command *cmd;
|
2010-02-05 21:57:42 +01:00
|
|
|
int argc;
|
2006-03-05 11:47:29 +01:00
|
|
|
const char **argv;
|
2014-08-19 21:09:35 +02:00
|
|
|
struct child_process proc = CHILD_PROCESS_INIT;
|
2013-01-13 06:17:02 +01:00
|
|
|
char *hook;
|
2005-08-02 23:24:22 +02:00
|
|
|
|
2013-01-13 06:17:02 +01:00
|
|
|
hook = find_hook("post-update");
|
2010-04-20 00:08:30 +02:00
|
|
|
for (argc = 0, cmd = commands; cmd; cmd = cmd->next) {
|
2011-09-28 17:39:35 +02:00
|
|
|
if (cmd->error_string || cmd->did_not_exist)
|
2005-08-02 23:24:22 +02:00
|
|
|
continue;
|
|
|
|
argc++;
|
|
|
|
}
|
2013-01-13 06:17:02 +01:00
|
|
|
if (!argc || !hook)
|
2007-03-07 22:50:43 +01:00
|
|
|
return;
|
2013-01-13 06:17:02 +01:00
|
|
|
|
2007-03-07 22:50:43 +01:00
|
|
|
argv = xmalloc(sizeof(*argv) * (2 + argc));
|
2013-01-13 06:17:02 +01:00
|
|
|
argv[0] = hook;
|
2005-08-02 23:24:22 +02:00
|
|
|
|
2010-04-20 00:08:30 +02:00
|
|
|
for (argc = 1, cmd = commands; cmd; cmd = cmd->next) {
|
2011-09-28 17:39:35 +02:00
|
|
|
if (cmd->error_string || cmd->did_not_exist)
|
2005-08-02 23:24:22 +02:00
|
|
|
continue;
|
2014-06-19 23:19:43 +02:00
|
|
|
argv[argc] = xstrdup(cmd->ref_name);
|
2005-08-02 23:24:22 +02:00
|
|
|
argc++;
|
|
|
|
}
|
|
|
|
argv[argc] = NULL;
|
2010-02-05 21:57:42 +01:00
|
|
|
|
|
|
|
proc.no_stdin = 1;
|
|
|
|
proc.stdout_to_stderr = 1;
|
|
|
|
proc.err = use_sideband ? -1 : 0;
|
|
|
|
proc.argv = argv;
|
|
|
|
|
|
|
|
if (!start_command(&proc)) {
|
|
|
|
if (use_sideband)
|
|
|
|
copy_to_sideband(proc.err, -1, NULL);
|
|
|
|
finish_command(&proc);
|
|
|
|
}
|
2005-08-02 23:24:22 +02:00
|
|
|
}
|
2005-06-30 19:15:22 +02:00
|
|
|
|
2010-04-20 00:19:18 +02:00
|
|
|
static void check_aliased_update(struct command *cmd, struct string_list *list)
|
|
|
|
{
|
2011-07-09 01:13:32 +02:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
const char *dst_name;
|
2010-04-20 00:19:18 +02:00
|
|
|
struct string_list_item *item;
|
|
|
|
struct command *dst_cmd;
|
|
|
|
unsigned char sha1[20];
|
|
|
|
char cmd_oldh[41], cmd_newh[41], dst_oldh[41], dst_newh[41];
|
|
|
|
int flag;
|
|
|
|
|
2011-07-09 01:13:32 +02:00
|
|
|
strbuf_addf(&buf, "%s%s", get_git_namespace(), cmd->ref_name);
|
2011-12-12 12:20:32 +01:00
|
|
|
dst_name = resolve_ref_unsafe(buf.buf, sha1, 0, &flag);
|
2011-07-09 01:13:32 +02:00
|
|
|
strbuf_release(&buf);
|
2010-04-20 00:19:18 +02:00
|
|
|
|
|
|
|
if (!(flag & REF_ISSYMREF))
|
|
|
|
return;
|
|
|
|
|
2011-07-09 01:13:32 +02:00
|
|
|
dst_name = strip_namespace(dst_name);
|
|
|
|
if (!dst_name) {
|
|
|
|
rp_error("refusing update to broken symref '%s'", cmd->ref_name);
|
|
|
|
cmd->skip_update = 1;
|
|
|
|
cmd->error_string = "broken symref";
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2010-06-26 01:41:37 +02:00
|
|
|
if ((item = string_list_lookup(list, dst_name)) == NULL)
|
2010-04-20 00:19:18 +02:00
|
|
|
return;
|
|
|
|
|
|
|
|
cmd->skip_update = 1;
|
|
|
|
|
|
|
|
dst_cmd = (struct command *) item->util;
|
|
|
|
|
|
|
|
if (!hashcmp(cmd->old_sha1, dst_cmd->old_sha1) &&
|
|
|
|
!hashcmp(cmd->new_sha1, dst_cmd->new_sha1))
|
|
|
|
return;
|
|
|
|
|
|
|
|
dst_cmd->skip_update = 1;
|
|
|
|
|
|
|
|
strcpy(cmd_oldh, find_unique_abbrev(cmd->old_sha1, DEFAULT_ABBREV));
|
2010-06-10 20:43:51 +02:00
|
|
|
strcpy(cmd_newh, find_unique_abbrev(cmd->new_sha1, DEFAULT_ABBREV));
|
2010-04-20 00:19:18 +02:00
|
|
|
strcpy(dst_oldh, find_unique_abbrev(dst_cmd->old_sha1, DEFAULT_ABBREV));
|
2010-06-10 20:43:51 +02:00
|
|
|
strcpy(dst_newh, find_unique_abbrev(dst_cmd->new_sha1, DEFAULT_ABBREV));
|
2010-04-20 00:19:18 +02:00
|
|
|
rp_error("refusing inconsistent update between symref '%s' (%s..%s) and"
|
|
|
|
" its target '%s' (%s..%s)",
|
|
|
|
cmd->ref_name, cmd_oldh, cmd_newh,
|
|
|
|
dst_cmd->ref_name, dst_oldh, dst_newh);
|
|
|
|
|
|
|
|
cmd->error_string = dst_cmd->error_string =
|
|
|
|
"inconsistent aliased update";
|
|
|
|
}
|
|
|
|
|
|
|
|
static void check_aliased_updates(struct command *commands)
|
|
|
|
{
|
|
|
|
struct command *cmd;
|
2010-07-04 21:46:19 +02:00
|
|
|
struct string_list ref_list = STRING_LIST_INIT_NODUP;
|
2010-04-20 00:19:18 +02:00
|
|
|
|
|
|
|
for (cmd = commands; cmd; cmd = cmd->next) {
|
|
|
|
struct string_list_item *item =
|
2010-06-26 01:41:38 +02:00
|
|
|
string_list_append(&ref_list, cmd->ref_name);
|
2010-04-20 00:19:18 +02:00
|
|
|
item->util = (void *)cmd;
|
|
|
|
}
|
|
|
|
sort_string_list(&ref_list);
|
|
|
|
|
2012-02-13 21:17:12 +01:00
|
|
|
for (cmd = commands; cmd; cmd = cmd->next) {
|
|
|
|
if (!cmd->error_string)
|
|
|
|
check_aliased_update(cmd, &ref_list);
|
|
|
|
}
|
2010-04-20 00:19:18 +02:00
|
|
|
|
|
|
|
string_list_clear(&ref_list, 0);
|
|
|
|
}
|
|
|
|
|
2011-09-03 01:52:08 +02:00
|
|
|
static int command_singleton_iterator(void *cb_data, unsigned char sha1[20])
|
|
|
|
{
|
|
|
|
struct command **cmd_list = cb_data;
|
|
|
|
struct command *cmd = *cmd_list;
|
|
|
|
|
2011-11-03 20:15:08 +01:00
|
|
|
if (!cmd || is_null_sha1(cmd->new_sha1))
|
2011-09-03 01:52:08 +02:00
|
|
|
return -1; /* end of list */
|
|
|
|
*cmd_list = NULL; /* this returns only one */
|
|
|
|
hashcpy(sha1, cmd->new_sha1);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-12-05 14:02:47 +01:00
|
|
|
static void set_connectivity_errors(struct command *commands,
|
|
|
|
struct shallow_info *si)
|
2011-09-03 01:52:08 +02:00
|
|
|
{
|
|
|
|
struct command *cmd;
|
|
|
|
|
|
|
|
for (cmd = commands; cmd; cmd = cmd->next) {
|
|
|
|
struct command *singleton = cmd;
|
2013-12-05 14:02:47 +01:00
|
|
|
if (shallow_update && si->shallow_ref[cmd->index])
|
|
|
|
/* to be checked in update_shallow_ref() */
|
|
|
|
continue;
|
2011-09-03 01:52:08 +02:00
|
|
|
if (!check_everything_connected(command_singleton_iterator,
|
|
|
|
0, &singleton))
|
|
|
|
continue;
|
|
|
|
cmd->error_string = "missing necessary objects";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-12-05 14:02:47 +01:00
|
|
|
struct iterate_data {
|
|
|
|
struct command *cmds;
|
|
|
|
struct shallow_info *si;
|
|
|
|
};
|
|
|
|
|
2011-09-03 01:52:08 +02:00
|
|
|
static int iterate_receive_command_list(void *cb_data, unsigned char sha1[20])
|
|
|
|
{
|
2013-12-05 14:02:47 +01:00
|
|
|
struct iterate_data *data = cb_data;
|
|
|
|
struct command **cmd_list = &data->cmds;
|
2011-09-03 01:52:08 +02:00
|
|
|
struct command *cmd = *cmd_list;
|
|
|
|
|
2013-12-05 14:02:47 +01:00
|
|
|
for (; cmd; cmd = cmd->next) {
|
|
|
|
if (shallow_update && data->si->shallow_ref[cmd->index])
|
|
|
|
/* to be checked in update_shallow_ref() */
|
|
|
|
continue;
|
2013-12-05 14:02:44 +01:00
|
|
|
if (!is_null_sha1(cmd->new_sha1) && !cmd->skip_update) {
|
2011-11-03 20:15:08 +01:00
|
|
|
hashcpy(sha1, cmd->new_sha1);
|
|
|
|
*cmd_list = cmd->next;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
*cmd_list = NULL;
|
|
|
|
return -1; /* end of list */
|
2011-09-03 01:52:08 +02: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 01:08:30 +01:00
|
|
|
static void reject_updates_to_hidden(struct command *commands)
|
|
|
|
{
|
|
|
|
struct command *cmd;
|
|
|
|
|
|
|
|
for (cmd = commands; cmd; cmd = cmd->next) {
|
|
|
|
if (cmd->error_string || !ref_is_hidden(cmd->ref_name))
|
|
|
|
continue;
|
|
|
|
if (is_null_sha1(cmd->new_sha1))
|
|
|
|
cmd->error_string = "deny deleting a hidden ref";
|
|
|
|
else
|
|
|
|
cmd->error_string = "deny updating a hidden ref";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-12-05 14:02:47 +01:00
|
|
|
static void execute_commands(struct command *commands,
|
|
|
|
const char *unpacker_error,
|
|
|
|
struct shallow_info *si)
|
2005-06-30 02:52:11 +02:00
|
|
|
{
|
2013-12-05 14:02:47 +01:00
|
|
|
int checked_connectivity;
|
2010-04-20 00:08:30 +02:00
|
|
|
struct command *cmd;
|
2009-02-09 07:31:21 +01:00
|
|
|
unsigned char sha1[20];
|
2013-12-05 14:02:47 +01:00
|
|
|
struct iterate_data data;
|
2007-03-07 22:51:59 +01:00
|
|
|
|
|
|
|
if (unpacker_error) {
|
2010-04-20 00:08:30 +02:00
|
|
|
for (cmd = commands; cmd; cmd = cmd->next)
|
2012-09-21 07:38:46 +02:00
|
|
|
cmd->error_string = "unpacker error";
|
2007-03-07 22:51:59 +01:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-12-05 14:02:47 +01:00
|
|
|
data.cmds = commands;
|
|
|
|
data.si = si;
|
|
|
|
if (check_everything_connected(iterate_receive_command_list, 0, &data))
|
|
|
|
set_connectivity_errors(commands, si);
|
2011-09-03 01:52:08 +02: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 01:08:30 +01:00
|
|
|
reject_updates_to_hidden(commands);
|
|
|
|
|
2013-01-13 06:17:02 +01:00
|
|
|
if (run_receive_hook(commands, "pre-receive", 0)) {
|
2012-02-13 21:17:12 +01:00
|
|
|
for (cmd = commands; cmd; cmd = cmd->next) {
|
|
|
|
if (!cmd->error_string)
|
|
|
|
cmd->error_string = "pre-receive hook declined";
|
|
|
|
}
|
2007-03-07 22:52:05 +01:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2010-04-20 00:19:18 +02:00
|
|
|
check_aliased_updates(commands);
|
|
|
|
|
2011-12-13 15:17:48 +01:00
|
|
|
free(head_name_to_free);
|
|
|
|
head_name = head_name_to_free = resolve_refdup("HEAD", sha1, 0, NULL);
|
2009-02-09 07:31:21 +01:00
|
|
|
|
2013-12-05 14:02:47 +01:00
|
|
|
checked_connectivity = 1;
|
2012-02-13 21:17:12 +01:00
|
|
|
for (cmd = commands; cmd; cmd = cmd->next) {
|
|
|
|
if (cmd->error_string)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (cmd->skip_update)
|
|
|
|
continue;
|
|
|
|
|
2013-12-05 14:02:47 +01:00
|
|
|
cmd->error_string = update(cmd, si);
|
|
|
|
if (shallow_update && !cmd->error_string &&
|
|
|
|
si->shallow_ref[cmd->index]) {
|
|
|
|
error("BUG: connectivity check has not been run on ref %s",
|
|
|
|
cmd->ref_name);
|
|
|
|
checked_connectivity = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-02-27 12:25:20 +01:00
|
|
|
if (shallow_update && !checked_connectivity)
|
|
|
|
error("BUG: run 'git fsck' for safety.\n"
|
|
|
|
"If there are errors, try to remove "
|
|
|
|
"the reported refs above");
|
2005-06-30 02:52:11 +02:00
|
|
|
}
|
|
|
|
|
2014-08-15 23:28:28 +02:00
|
|
|
static struct command **queue_command(struct command **tail,
|
|
|
|
const char *line,
|
|
|
|
int linelen)
|
|
|
|
{
|
|
|
|
unsigned char old_sha1[20], new_sha1[20];
|
|
|
|
struct command *cmd;
|
|
|
|
const char *refname;
|
|
|
|
int reflen;
|
|
|
|
|
|
|
|
if (linelen < 83 ||
|
|
|
|
line[40] != ' ' ||
|
|
|
|
line[81] != ' ' ||
|
|
|
|
get_sha1_hex(line, old_sha1) ||
|
|
|
|
get_sha1_hex(line + 41, new_sha1))
|
|
|
|
die("protocol error: expected old/new/ref, got '%s'", line);
|
|
|
|
|
|
|
|
refname = line + 82;
|
|
|
|
reflen = linelen - 82;
|
|
|
|
cmd = xcalloc(1, sizeof(struct command) + reflen + 1);
|
|
|
|
hashcpy(cmd->old_sha1, old_sha1);
|
|
|
|
hashcpy(cmd->new_sha1, new_sha1);
|
|
|
|
memcpy(cmd->ref_name, refname, reflen);
|
|
|
|
cmd->ref_name[reflen] = '\0';
|
|
|
|
*tail = cmd;
|
|
|
|
return &cmd->next;
|
|
|
|
}
|
|
|
|
|
2014-08-18 23:38:45 +02: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;
|
|
|
|
eoc = push_cert->buf + parse_signature(push_cert->buf, push_cert->len);
|
|
|
|
|
|
|
|
while (boc < eoc) {
|
|
|
|
const char *eol = memchr(boc, '\n', eoc - boc);
|
|
|
|
tail = queue_command(tail, boc, eol ? eol - boc : eoc - eol);
|
|
|
|
boc = eol ? eol + 1 : eoc;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-12-05 14:02:44 +01:00
|
|
|
static struct command *read_head_info(struct sha1_array *shallow)
|
2005-06-30 02:52:11 +02:00
|
|
|
{
|
2010-04-20 00:08:30 +02:00
|
|
|
struct command *commands = NULL;
|
2005-06-30 08:01:14 +02:00
|
|
|
struct command **p = &commands;
|
2005-06-30 02:52:11 +02:00
|
|
|
for (;;) {
|
pkt-line: provide a LARGE_PACKET_MAX static buffer
Most of the callers of packet_read_line just read into a
static 1000-byte buffer (callers which handle arbitrary
binary data already use LARGE_PACKET_MAX). This works fine
in practice, because:
1. The only variable-sized data in these lines is a ref
name, and refs tend to be a lot shorter than 1000
characters.
2. When sending ref lines, git-core always limits itself
to 1000 byte packets.
However, the only limit given in the protocol specification
in Documentation/technical/protocol-common.txt is
LARGE_PACKET_MAX; the 1000 byte limit is mentioned only in
pack-protocol.txt, and then only describing what we write,
not as a specific limit for readers.
This patch lets us bump the 1000-byte limit to
LARGE_PACKET_MAX. Even though git-core will never write a
packet where this makes a difference, there are two good
reasons to do this:
1. Other git implementations may have followed
protocol-common.txt and used a larger maximum size. We
don't bump into it in practice because it would involve
very long ref names.
2. We may want to increase the 1000-byte limit one day.
Since packets are transferred before any capabilities,
it's difficult to do this in a backwards-compatible
way. But if we bump the size of buffer the readers can
handle, eventually older versions of git will be
obsolete enough that we can justify bumping the
writers, as well. We don't have plans to do this
anytime soon, but there is no reason not to start the
clock ticking now.
Just bumping all of the reading bufs to LARGE_PACKET_MAX
would waste memory. Instead, since most readers just read
into a temporary buffer anyway, let's provide a single
static buffer that all callers can use. We can further wrap
this detail away by having the packet_read_line wrapper just
use the buffer transparently and return a pointer to the
static storage. That covers most of the cases, and the
remaining ones already read into their own LARGE_PACKET_MAX
buffers.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-20 21:02:57 +01:00
|
|
|
char *line;
|
2014-08-15 23:28:28 +02:00
|
|
|
int len, linelen;
|
2005-06-30 08:01:14 +02:00
|
|
|
|
pkt-line: provide a LARGE_PACKET_MAX static buffer
Most of the callers of packet_read_line just read into a
static 1000-byte buffer (callers which handle arbitrary
binary data already use LARGE_PACKET_MAX). This works fine
in practice, because:
1. The only variable-sized data in these lines is a ref
name, and refs tend to be a lot shorter than 1000
characters.
2. When sending ref lines, git-core always limits itself
to 1000 byte packets.
However, the only limit given in the protocol specification
in Documentation/technical/protocol-common.txt is
LARGE_PACKET_MAX; the 1000 byte limit is mentioned only in
pack-protocol.txt, and then only describing what we write,
not as a specific limit for readers.
This patch lets us bump the 1000-byte limit to
LARGE_PACKET_MAX. Even though git-core will never write a
packet where this makes a difference, there are two good
reasons to do this:
1. Other git implementations may have followed
protocol-common.txt and used a larger maximum size. We
don't bump into it in practice because it would involve
very long ref names.
2. We may want to increase the 1000-byte limit one day.
Since packets are transferred before any capabilities,
it's difficult to do this in a backwards-compatible
way. But if we bump the size of buffer the readers can
handle, eventually older versions of git will be
obsolete enough that we can justify bumping the
writers, as well. We don't have plans to do this
anytime soon, but there is no reason not to start the
clock ticking now.
Just bumping all of the reading bufs to LARGE_PACKET_MAX
would waste memory. Instead, since most readers just read
into a temporary buffer anyway, let's provide a single
static buffer that all callers can use. We can further wrap
this detail away by having the packet_read_line wrapper just
use the buffer transparently and return a pointer to the
static storage. That covers most of the cases, and the
remaining ones already read into their own LARGE_PACKET_MAX
buffers.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-20 21:02:57 +01:00
|
|
|
line = packet_read_line(0, &len);
|
|
|
|
if (!line)
|
2005-06-30 02:52:11 +02:00
|
|
|
break;
|
2013-12-05 14:02:44 +01:00
|
|
|
|
2014-01-17 21:21:14 +01:00
|
|
|
if (len == 48 && starts_with(line, "shallow ")) {
|
2014-08-15 23:26:17 +02:00
|
|
|
unsigned char sha1[20];
|
|
|
|
if (get_sha1_hex(line + 8, sha1))
|
|
|
|
die("protocol error: expected shallow sha, got '%s'",
|
|
|
|
line + 8);
|
|
|
|
sha1_array_append(shallow, sha1);
|
2013-12-05 14:02:44 +01:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2014-08-15 23:11:33 +02:00
|
|
|
linelen = strlen(line);
|
|
|
|
if (linelen < len) {
|
|
|
|
const char *feature_list = line + linelen + 1;
|
2012-01-08 22:06:19 +01:00
|
|
|
if (parse_feature_request(feature_list, "report-status"))
|
2005-12-26 08:18:37 +01:00
|
|
|
report_status = 1;
|
2012-01-08 22:06:19 +01:00
|
|
|
if (parse_feature_request(feature_list, "side-band-64k"))
|
2010-02-05 21:57:41 +01:00
|
|
|
use_sideband = LARGE_PACKET_MAX;
|
2012-01-08 22:06:20 +01:00
|
|
|
if (parse_feature_request(feature_list, "quiet"))
|
|
|
|
quiet = 1;
|
2005-12-26 08:18:37 +01:00
|
|
|
}
|
2014-08-15 23:11:33 +02: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 20:17:07 +02:00
|
|
|
if (!strcmp(line, "push-cert")) {
|
|
|
|
int true_flush = 0;
|
|
|
|
char certbuf[1024];
|
|
|
|
|
|
|
|
for (;;) {
|
|
|
|
len = packet_read(0, NULL, NULL,
|
|
|
|
certbuf, sizeof(certbuf), 0);
|
|
|
|
if (!len) {
|
|
|
|
true_flush = 1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (!strcmp(certbuf, "push-cert-end\n"))
|
|
|
|
break; /* end of cert */
|
|
|
|
strbuf_addstr(&push_cert, certbuf);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (true_flush)
|
|
|
|
break;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2014-08-15 23:28:28 +02:00
|
|
|
p = queue_command(p, line, linelen);
|
2005-06-30 02:52:11 +02:00
|
|
|
}
|
2014-08-18 23:38:45 +02:00
|
|
|
|
|
|
|
if (push_cert.len)
|
|
|
|
queue_commands_from_cert(p, &push_cert);
|
|
|
|
|
2010-04-20 00:08:30 +02:00
|
|
|
return commands;
|
2005-06-30 02:52:11 +02:00
|
|
|
}
|
|
|
|
|
2006-11-01 23:06:21 +01:00
|
|
|
static const char *parse_pack_header(struct pack_header *hdr)
|
|
|
|
{
|
2007-01-23 06:55:18 +01: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 23:06:21 +01:00
|
|
|
return "protocol error (pack signature mismatch detected)";
|
2007-01-23 06:55:18 +01:00
|
|
|
|
|
|
|
case PH_ERROR_PROTOCOL:
|
2006-11-01 23:06:21 +01:00
|
|
|
return "protocol error (pack version unsupported)";
|
2007-01-23 06:55:18 +01:00
|
|
|
|
|
|
|
default:
|
|
|
|
return "unknown error in parse_pack_header";
|
|
|
|
|
|
|
|
case 0:
|
|
|
|
return NULL;
|
|
|
|
}
|
2006-11-01 23:06:21 +01:00
|
|
|
}
|
|
|
|
|
2006-11-01 23:06:25 +01:00
|
|
|
static const char *pack_lockfile;
|
|
|
|
|
2013-12-05 14:02:44 +01:00
|
|
|
static const char *unpack(int err_fd, struct shallow_info *si)
|
2005-06-30 02:52:11 +02:00
|
|
|
{
|
2006-11-01 23:06:21 +01:00
|
|
|
struct pack_header hdr;
|
2013-12-05 14:02:43 +01:00
|
|
|
struct argv_array av = ARGV_ARRAY_INIT;
|
2006-11-01 23:06:21 +01:00
|
|
|
const char *hdr_err;
|
2013-12-05 14:02:43 +01:00
|
|
|
int status;
|
2006-11-01 23:06:21 +01:00
|
|
|
char hdr_arg[38];
|
2014-08-19 21:09:35 +02:00
|
|
|
struct child_process child = CHILD_PROCESS_INIT;
|
2011-09-04 21:37:45 +02:00
|
|
|
int fsck_objects = (receive_fsck_objects >= 0
|
|
|
|
? receive_fsck_objects
|
|
|
|
: transfer_fsck_objects >= 0
|
|
|
|
? transfer_fsck_objects
|
|
|
|
: 0);
|
2006-11-01 23:06:21 +01: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 23:24:29 +02:00
|
|
|
if (hdr_err) {
|
|
|
|
if (err_fd > 0)
|
|
|
|
close(err_fd);
|
2006-11-01 23:06:21 +01: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 23:24:29 +02:00
|
|
|
}
|
2008-07-03 17:52:09 +02:00
|
|
|
snprintf(hdr_arg, sizeof(hdr_arg),
|
|
|
|
"--pack_header=%"PRIu32",%"PRIu32,
|
2006-11-01 23:06:21 +01:00
|
|
|
ntohl(hdr.hdr_version), ntohl(hdr.hdr_entries));
|
|
|
|
|
2013-12-05 14:02:44 +01:00
|
|
|
if (si->nr_ours || si->nr_theirs) {
|
|
|
|
alt_shallow_file = setup_temporary_shallow(si->shallow);
|
|
|
|
argv_array_pushl(&av, "--shallow-file", alt_shallow_file, NULL);
|
|
|
|
}
|
|
|
|
|
2006-11-01 23:06:21 +01:00
|
|
|
if (ntohl(hdr.hdr_entries) < unpack_limit) {
|
2013-12-05 14:02:43 +01:00
|
|
|
argv_array_pushl(&av, "unpack-objects", hdr_arg, NULL);
|
2012-01-08 22:06:20 +01:00
|
|
|
if (quiet)
|
2013-12-05 14:02:43 +01:00
|
|
|
argv_array_push(&av, "-q");
|
2011-09-04 21:37:45 +02:00
|
|
|
if (fsck_objects)
|
2013-12-05 14:02:43 +01:00
|
|
|
argv_array_push(&av, "--strict");
|
|
|
|
child.argv = av.argv;
|
2012-09-21 07:32:52 +02: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 07:34:55 +02:00
|
|
|
child.err = err_fd;
|
2012-09-21 07:32:52 +02:00
|
|
|
child.git_cmd = 1;
|
2013-12-05 14:02:43 +01:00
|
|
|
status = run_command(&child);
|
|
|
|
if (status)
|
|
|
|
return "unpack-objects abnormal exit";
|
2006-11-01 23:06:25 +01:00
|
|
|
} else {
|
2013-12-05 14:02:43 +01:00
|
|
|
int s;
|
2006-11-01 23:06:25 +01:00
|
|
|
char keep_arg[256];
|
|
|
|
|
2008-08-31 14:09:39 +02:00
|
|
|
s = sprintf(keep_arg, "--keep=receive-pack %"PRIuMAX" on ", (uintmax_t) getpid());
|
2006-11-01 23:06:25 +01:00
|
|
|
if (gethostname(keep_arg + s, sizeof(keep_arg) - s))
|
|
|
|
strcpy(keep_arg + s, "localhost");
|
|
|
|
|
2013-12-05 14:02:43 +01:00
|
|
|
argv_array_pushl(&av, "index-pack",
|
|
|
|
"--stdin", hdr_arg, keep_arg, NULL);
|
2011-09-04 21:37:45 +02:00
|
|
|
if (fsck_objects)
|
2013-12-05 14:02:43 +01:00
|
|
|
argv_array_push(&av, "--strict");
|
2013-08-12 15:55:55 +02:00
|
|
|
if (fix_thin)
|
2013-12-05 14:02:43 +01:00
|
|
|
argv_array_push(&av, "--fix-thin");
|
|
|
|
child.argv = av.argv;
|
|
|
|
child.out = -1;
|
|
|
|
child.err = err_fd;
|
|
|
|
child.git_cmd = 1;
|
|
|
|
status = start_command(&child);
|
|
|
|
if (status)
|
2006-11-01 23:06:25 +01:00
|
|
|
return "index-pack fork failed";
|
2013-12-05 14:02:43 +01:00
|
|
|
pack_lockfile = index_pack_lockfile(child.out);
|
|
|
|
close(child.out);
|
|
|
|
status = finish_command(&child);
|
|
|
|
if (status)
|
|
|
|
return "index-pack abnormal exit";
|
|
|
|
reprepare_packed_git();
|
2005-12-26 08:18:37 +01:00
|
|
|
}
|
2013-12-05 14:02:43 +01:00
|
|
|
return NULL;
|
2005-12-26 08:18:37 +01:00
|
|
|
}
|
|
|
|
|
2013-12-05 14:02:44 +01: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 07:34:55 +02:00
|
|
|
{
|
|
|
|
struct async muxer;
|
|
|
|
const char *ret;
|
|
|
|
|
|
|
|
if (!use_sideband)
|
2013-12-05 14:02:44 +01: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 07:34:55 +02:00
|
|
|
|
|
|
|
memset(&muxer, 0, sizeof(muxer));
|
|
|
|
muxer.proc = copy_to_sideband;
|
|
|
|
muxer.in = -1;
|
|
|
|
if (start_async(&muxer))
|
|
|
|
return NULL;
|
|
|
|
|
2013-12-05 14:02:44 +01: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 07:34:55 +02:00
|
|
|
|
|
|
|
finish_async(&muxer);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2013-12-05 14:02:47 +01:00
|
|
|
static void prepare_shallow_update(struct command *commands,
|
|
|
|
struct shallow_info *si)
|
|
|
|
{
|
|
|
|
int i, j, k, bitmap_size = (si->ref->nr + 31) / 32;
|
|
|
|
|
|
|
|
si->used_shallow = xmalloc(sizeof(*si->used_shallow) *
|
|
|
|
si->shallow->nr);
|
|
|
|
assign_shallow_commits_to_refs(si, si->used_shallow, NULL);
|
|
|
|
|
|
|
|
si->need_reachability_test =
|
|
|
|
xcalloc(si->shallow->nr, sizeof(*si->need_reachability_test));
|
|
|
|
si->reachable =
|
|
|
|
xcalloc(si->shallow->nr, sizeof(*si->reachable));
|
|
|
|
si->shallow_ref = xcalloc(si->ref->nr, sizeof(*si->shallow_ref));
|
|
|
|
|
|
|
|
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++)
|
|
|
|
if (si->used_shallow[i][j] & (1 << k))
|
|
|
|
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
|
|
|
|
* command. check_everything_connected() will be done with
|
|
|
|
* true .git/shallow though.
|
|
|
|
*/
|
|
|
|
setenv(GIT_SHALLOW_FILE_ENVIRONMENT, alt_shallow_file, 1);
|
|
|
|
}
|
|
|
|
|
2013-12-05 14:02:44 +01:00
|
|
|
static void update_shallow_info(struct command *commands,
|
|
|
|
struct shallow_info *si,
|
|
|
|
struct sha1_array *ref)
|
|
|
|
{
|
|
|
|
struct command *cmd;
|
|
|
|
int *ref_status;
|
|
|
|
remove_nonexistent_theirs_shallow(si);
|
2013-12-05 14:02:47 +01:00
|
|
|
if (!si->nr_ours && !si->nr_theirs) {
|
|
|
|
shallow_update = 0;
|
2013-12-05 14:02:44 +01:00
|
|
|
return;
|
2013-12-05 14:02:47 +01:00
|
|
|
}
|
2013-12-05 14:02:44 +01:00
|
|
|
|
|
|
|
for (cmd = commands; cmd; cmd = cmd->next) {
|
|
|
|
if (is_null_sha1(cmd->new_sha1))
|
|
|
|
continue;
|
|
|
|
sha1_array_append(ref, cmd->new_sha1);
|
|
|
|
cmd->index = ref->nr - 1;
|
|
|
|
}
|
|
|
|
si->ref = ref;
|
|
|
|
|
2013-12-05 14:02:47 +01:00
|
|
|
if (shallow_update) {
|
|
|
|
prepare_shallow_update(commands, si);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-12-05 14:02:44 +01:00
|
|
|
ref_status = xmalloc(sizeof(*ref_status) * ref->nr);
|
|
|
|
assign_shallow_commits_to_refs(si, NULL, ref_status);
|
|
|
|
for (cmd = commands; cmd; cmd = cmd->next) {
|
|
|
|
if (is_null_sha1(cmd->new_sha1))
|
|
|
|
continue;
|
|
|
|
if (ref_status[cmd->index]) {
|
|
|
|
cmd->error_string = "shallow update not allowed";
|
|
|
|
cmd->skip_update = 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
free(ref_status);
|
|
|
|
}
|
|
|
|
|
2010-04-20 00:08:30 +02:00
|
|
|
static void report(struct command *commands, const char *unpack_status)
|
2005-12-26 08:18:37 +01:00
|
|
|
{
|
|
|
|
struct command *cmd;
|
2010-02-05 21:57:41 +01:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
|
|
|
packet_buf_write(&buf, "unpack %s\n",
|
|
|
|
unpack_status ? unpack_status : "ok");
|
2005-12-26 08:18:37 +01:00
|
|
|
for (cmd = commands; cmd; cmd = cmd->next) {
|
|
|
|
if (!cmd->error_string)
|
2010-02-05 21:57:41 +01:00
|
|
|
packet_buf_write(&buf, "ok %s\n",
|
|
|
|
cmd->ref_name);
|
2005-12-26 08:18:37 +01:00
|
|
|
else
|
2010-02-05 21:57:41 +01:00
|
|
|
packet_buf_write(&buf, "ng %s %s\n",
|
|
|
|
cmd->ref_name, cmd->error_string);
|
2005-06-30 02:52:11 +02:00
|
|
|
}
|
2010-02-05 21:57:41 +01:00
|
|
|
packet_buf_flush(&buf);
|
|
|
|
|
|
|
|
if (use_sideband)
|
|
|
|
send_sideband(1, 1, buf.buf, buf.len, use_sideband);
|
|
|
|
else
|
2013-02-20 21:01:56 +01:00
|
|
|
write_or_die(1, buf.buf, buf.len);
|
2010-02-05 21:57:41 +01:00
|
|
|
strbuf_release(&buf);
|
2005-06-30 02:52:11 +02:00
|
|
|
}
|
|
|
|
|
2010-04-20 00:08:30 +02:00
|
|
|
static int delete_only(struct command *commands)
|
2006-11-24 09:26:49 +01:00
|
|
|
{
|
2010-04-20 00:08:30 +02:00
|
|
|
struct command *cmd;
|
|
|
|
for (cmd = commands; cmd; cmd = cmd->next) {
|
2006-11-24 09:26:49 +01:00
|
|
|
if (!is_null_sha1(cmd->new_sha1))
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2008-09-09 10:27:08 +02:00
|
|
|
int cmd_receive_pack(int argc, const char **argv, const char *prefix)
|
2005-06-30 02:52:11 +02:00
|
|
|
{
|
2009-10-31 01:47:33 +01:00
|
|
|
int advertise_refs = 0;
|
2005-06-30 21:28:24 +02:00
|
|
|
int i;
|
2010-04-20 00:08:30 +02:00
|
|
|
struct command *commands;
|
2013-12-05 14:02:44 +01:00
|
|
|
struct sha1_array shallow = SHA1_ARRAY_INIT;
|
|
|
|
struct sha1_array ref = SHA1_ARRAY_INIT;
|
|
|
|
struct shallow_info si;
|
2005-06-30 02:52:11 +02:00
|
|
|
|
2011-02-24 15:30:19 +01:00
|
|
|
packet_trace_identity("receive-pack");
|
|
|
|
|
2005-06-30 02:52:11 +02:00
|
|
|
argv++;
|
|
|
|
for (i = 1; i < argc; i++) {
|
2008-09-09 10:27:08 +02:00
|
|
|
const char *arg = *argv++;
|
2005-06-30 02:52:11 +02:00
|
|
|
|
|
|
|
if (*arg == '-') {
|
2012-01-08 22:06:20 +01:00
|
|
|
if (!strcmp(arg, "--quiet")) {
|
|
|
|
quiet = 1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2009-10-31 01:47:33 +01:00
|
|
|
if (!strcmp(arg, "--advertise-refs")) {
|
|
|
|
advertise_refs = 1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!strcmp(arg, "--stateless-rpc")) {
|
|
|
|
stateless_rpc = 1;
|
|
|
|
continue;
|
|
|
|
}
|
2013-08-12 15:55:55 +02:00
|
|
|
if (!strcmp(arg, "--reject-thin-pack-for-testing")) {
|
|
|
|
fix_thin = 0;
|
|
|
|
continue;
|
|
|
|
}
|
2009-10-31 01:47:33 +01:00
|
|
|
|
2005-06-30 02:52:11 +02:00
|
|
|
usage(receive_pack_usage);
|
|
|
|
}
|
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 19:46:04 +02:00
|
|
|
if (service_dir)
|
2005-06-30 21:28:24 +02:00
|
|
|
usage(receive_pack_usage);
|
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 19:46:04 +02:00
|
|
|
service_dir = arg;
|
2005-06-30 02:52:11 +02: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 19:46:04 +02:00
|
|
|
if (!service_dir)
|
2005-06-30 02:52:11 +02:00
|
|
|
usage(receive_pack_usage);
|
|
|
|
|
2008-07-21 21:19:52 +02:00
|
|
|
setup_path();
|
2008-03-03 05:08:43 +01: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 19:46:04 +02:00
|
|
|
if (!enter_repo(service_dir, 0))
|
|
|
|
die("'%s' does not appear to be a git repository", service_dir);
|
2005-06-30 02:52:11 +02:00
|
|
|
|
2008-05-14 19:46:53 +02:00
|
|
|
git_config(receive_pack_config, NULL);
|
2014-08-22 01:45:30 +02: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 19:46:04 +02:00
|
|
|
push_cert_nonce = prepare_push_cert_nonce(service_dir, time(NULL));
|
2006-10-30 23:35:18 +01:00
|
|
|
|
2007-01-25 02:02:15 +01:00
|
|
|
if (0 <= transfer_unpack_limit)
|
|
|
|
unpack_limit = transfer_unpack_limit;
|
|
|
|
else if (0 <= receive_unpack_limit)
|
|
|
|
unpack_limit = receive_unpack_limit;
|
|
|
|
|
2009-10-31 01:47:33 +01:00
|
|
|
if (advertise_refs || !stateless_rpc) {
|
|
|
|
write_head_info();
|
|
|
|
}
|
|
|
|
if (advertise_refs)
|
|
|
|
return 0;
|
2005-06-30 02:52:11 +02:00
|
|
|
|
2013-12-05 14:02:44 +01:00
|
|
|
if ((commands = read_head_info(&shallow)) != NULL) {
|
2006-11-24 09:26:49 +01:00
|
|
|
const char *unpack_status = NULL;
|
|
|
|
|
2013-12-05 14:02:44 +01:00
|
|
|
prepare_shallow_info(&si, &shallow);
|
2013-12-05 14:02:47 +01:00
|
|
|
if (!si.nr_ours && !si.nr_theirs)
|
|
|
|
shallow_update = 0;
|
2013-12-05 14:02:44 +01:00
|
|
|
if (!delete_only(commands)) {
|
|
|
|
unpack_status = unpack_with_sideband(&si);
|
|
|
|
update_shallow_info(commands, &si, &ref);
|
|
|
|
}
|
2013-12-05 14:02:47 +01:00
|
|
|
execute_commands(commands, unpack_status, &si);
|
2006-11-01 23:06:25 +01:00
|
|
|
if (pack_lockfile)
|
2009-04-29 23:22:56 +02:00
|
|
|
unlink_or_warn(pack_lockfile);
|
2005-12-26 08:18:37 +01:00
|
|
|
if (report_status)
|
2010-04-20 00:08:30 +02:00
|
|
|
report(commands, unpack_status);
|
2013-01-13 06:17:02 +01:00
|
|
|
run_receive_hook(commands, "post-receive", 1);
|
2007-03-07 22:50:24 +01:00
|
|
|
run_update_post_hook(commands);
|
2009-10-20 23:56:40 +02:00
|
|
|
if (auto_gc) {
|
|
|
|
const char *argv_gc_auto[] = {
|
|
|
|
"gc", "--auto", "--quiet", NULL,
|
|
|
|
};
|
2012-08-07 07:31:10 +02:00
|
|
|
int opt = RUN_GIT_CMD | RUN_COMMAND_STDOUT_TO_STDERR;
|
|
|
|
run_command_v_opt(argv_gc_auto, opt);
|
2009-10-20 23:56:40 +02:00
|
|
|
}
|
|
|
|
if (auto_update_server_info)
|
|
|
|
update_server_info(0);
|
2013-12-05 14:02:44 +01:00
|
|
|
clear_shallow_info(&si);
|
2005-06-30 07:50:48 +02:00
|
|
|
}
|
2010-02-05 21:57:41 +01:00
|
|
|
if (use_sideband)
|
|
|
|
packet_flush(1);
|
2013-12-05 14:02:44 +01:00
|
|
|
sha1_array_clear(&shallow);
|
|
|
|
sha1_array_clear(&ref);
|
2014-08-22 01:45:30 +02:00
|
|
|
free((void *)push_cert_nonce);
|
2005-06-30 02:52:11 +02:00
|
|
|
return 0;
|
|
|
|
}
|