|
|
|
|
#include "builtin.h"
|
|
|
|
|
#include "commit.h"
|
|
|
|
|
#include "refs.h"
|
|
|
|
|
#include "pkt-line.h"
|
|
|
|
|
#include "sideband.h"
|
|
|
|
|
#include "run-command.h"
|
|
|
|
|
#include "remote.h"
|
|
|
|
|
#include "connect.h"
|
|
|
|
|
#include "send-pack.h"
|
|
|
|
|
#include "quote.h"
|
|
|
|
|
#include "transport.h"
|
|
|
|
|
#include "version.h"
|
|
|
|
|
#include "sha1-array.h"
|
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>
10 years ago
|
|
|
#include "gpg-interface.h"
|
|
|
|
|
|
|
|
|
|
static int feed_object(const unsigned char *sha1, int fd, int negative)
|
|
|
|
|
{
|
|
|
|
|
char buf[42];
|
|
|
|
|
|
|
|
|
|
if (negative && !has_sha1_file(sha1))
|
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
|
|
memcpy(buf + negative, sha1_to_hex(sha1), 40);
|
|
|
|
|
if (negative)
|
|
|
|
|
buf[0] = '^';
|
|
|
|
|
buf[40 + negative] = '\n';
|
|
|
|
|
return write_or_whine(fd, buf, 41 + negative, "send-pack: send refs");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Make a pack stream and spit it out into file descriptor fd
|
|
|
|
|
*/
|
|
|
|
|
static int pack_objects(int fd, struct ref *refs, struct sha1_array *extra, struct send_pack_args *args)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* The child becomes pack-objects --revs; we feed
|
|
|
|
|
* the revision parameters to it via its stdin and
|
|
|
|
|
* let its stdout go back to the other end.
|
|
|
|
|
*/
|
|
|
|
|
const char *argv[] = {
|
|
|
|
|
"pack-objects",
|
|
|
|
|
"--all-progress-implied",
|
|
|
|
|
"--revs",
|
|
|
|
|
"--stdout",
|
|
|
|
|
NULL,
|
|
|
|
|
NULL,
|
|
|
|
|
NULL,
|
|
|
|
|
NULL,
|
|
|
|
|
NULL,
|
|
|
|
|
NULL,
|
|
|
|
|
};
|
|
|
|
|
struct child_process po = CHILD_PROCESS_INIT;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
i = 4;
|
|
|
|
|
if (args->use_thin_pack)
|
|
|
|
|
argv[i++] = "--thin";
|
|
|
|
|
if (args->use_ofs_delta)
|
|
|
|
|
argv[i++] = "--delta-base-offset";
|
|
|
|
|
if (args->quiet || !args->progress)
|
|
|
|
|
argv[i++] = "-q";
|
|
|
|
|
if (args->progress)
|
|
|
|
|
argv[i++] = "--progress";
|
|
|
|
|
if (is_repository_shallow())
|
|
|
|
|
argv[i++] = "--shallow";
|
|
|
|
|
po.argv = argv;
|
|
|
|
|
po.in = -1;
|
|
|
|
|
po.out = args->stateless_rpc ? -1 : fd;
|
|
|
|
|
po.git_cmd = 1;
|
|
|
|
|
if (start_command(&po))
|
|
|
|
|
die_errno("git pack-objects failed");
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We feed the pack-objects we just spawned with revision
|
|
|
|
|
* parameters by writing to the pipe.
|
|
|
|
|
*/
|
|
|
|
|
for (i = 0; i < extra->nr; i++)
|
|
|
|
|
if (!feed_object(extra->sha1[i], po.in, 1))
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
while (refs) {
|
|
|
|
|
if (!is_null_sha1(refs->old_sha1) &&
|
|
|
|
|
!feed_object(refs->old_sha1, po.in, 1))
|
|
|
|
|
break;
|
|
|
|
|
if (!is_null_sha1(refs->new_sha1) &&
|
|
|
|
|
!feed_object(refs->new_sha1, po.in, 0))
|
|
|
|
|
break;
|
|
|
|
|
refs = refs->next;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
close(po.in);
|
|
|
|
|
|
|
|
|
|
if (args->stateless_rpc) {
|
|
|
|
|
char *buf = xmalloc(LARGE_PACKET_MAX);
|
|
|
|
|
while (1) {
|
|
|
|
|
ssize_t n = xread(po.out, buf, LARGE_PACKET_MAX);
|
|
|
|
|
if (n <= 0)
|
|
|
|
|
break;
|
|
|
|
|
send_sideband(fd, -1, buf, n, LARGE_PACKET_MAX);
|
|
|
|
|
}
|
|
|
|
|
free(buf);
|
|
|
|
|
close(po.out);
|
|
|
|
|
po.out = -1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (finish_command(&po))
|
|
|
|
|
return -1;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int receive_status(int in, struct ref *refs)
|
|
|
|
|
{
|
|
|
|
|
struct ref *hint;
|
|
|
|
|
int ret = 0;
|
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>
12 years ago
|
|
|
char *line = packet_read_line(in, NULL);
|
|
|
|
|
if (!starts_with(line, "unpack "))
|
|
|
|
|
return error("did not receive remote status");
|
pkt-line: teach packet_read_line to chomp newlines
The packets sent during ref negotiation are all terminated
by newline; even though the code to chomp these newlines is
short, we end up doing it in a lot of places.
This patch teaches packet_read_line to auto-chomp the
trailing newline; this lets us get rid of a lot of inline
chomping code.
As a result, some call-sites which are not reading
line-oriented data (e.g., when reading chunks of packfiles
alongside sideband) transition away from packet_read_line to
the generic packet_read interface. This patch converts all
of the existing callsites.
Since the function signature of packet_read_line does not
change (but its behavior does), there is a possibility of
new callsites being introduced in later commits, silently
introducing an incompatibility. However, since a later
patch in this series will change the signature, such a
commit would have to be merged directly into this commit,
not to the tip of the series; we can therefore ignore the
issue.
This is an internal cleanup and should produce no change of
behavior in the normal case. However, there is one corner
case to note. Callers of packet_read_line have never been
able to tell the difference between a flush packet ("0000")
and an empty packet ("0004"), as both cause packet_read_line
to return a length of 0. Readers treat them identically,
even though Documentation/technical/protocol-common.txt says
we must not; it also says that implementations should not
send an empty pkt-line.
By stripping out the newline before the result gets to the
caller, we will now treat the newline-only packet ("0005\n")
the same as an empty packet, which in turn gets treated like
a flush packet. In practice this doesn't matter, as neither
empty nor newline-only packets are part of git's protocols
(at least not for the line-oriented bits, and readers who
are not expecting line-oriented packets will be calling
packet_read directly, anyway). But even if we do decide to
care about the distinction later, it is orthogonal to this
patch. The right place to tighten would be to stop treating
empty packets as flush packets, and this change does not
make doing so any harder.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
12 years ago
|
|
|
if (strcmp(line, "unpack ok")) {
|
|
|
|
|
error("unpack failed: %s", line + 7);
|
|
|
|
|
ret = -1;
|
|
|
|
|
}
|
|
|
|
|
hint = NULL;
|
|
|
|
|
while (1) {
|
|
|
|
|
char *refname;
|
|
|
|
|
char *msg;
|
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>
12 years ago
|
|
|
line = packet_read_line(in, NULL);
|
|
|
|
|
if (!line)
|
|
|
|
|
break;
|
|
|
|
|
if (!starts_with(line, "ok ") && !starts_with(line, "ng ")) {
|
|
|
|
|
error("invalid ref status from remote: %s", line);
|
|
|
|
|
ret = -1;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
refname = line + 3;
|
|
|
|
|
msg = strchr(refname, ' ');
|
|
|
|
|
if (msg)
|
|
|
|
|
*msg++ = '\0';
|
|
|
|
|
|
|
|
|
|
/* first try searching at our hint, falling back to all refs */
|
|
|
|
|
if (hint)
|
|
|
|
|
hint = find_ref_by_name(hint, refname);
|
|
|
|
|
if (!hint)
|
|
|
|
|
hint = find_ref_by_name(refs, refname);
|
|
|
|
|
if (!hint) {
|
|
|
|
|
warning("remote reported status on unknown ref: %s",
|
|
|
|
|
refname);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
if (hint->status != REF_STATUS_EXPECTING_REPORT) {
|
|
|
|
|
warning("remote reported status on unexpected ref: %s",
|
|
|
|
|
refname);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (line[0] == 'o' && line[1] == 'k')
|
|
|
|
|
hint->status = REF_STATUS_OK;
|
|
|
|
|
else {
|
|
|
|
|
hint->status = REF_STATUS_REMOTE_REJECT;
|
|
|
|
|
ret = -1;
|
|
|
|
|
}
|
|
|
|
|
if (msg)
|
|
|
|
|
hint->remote_status = xstrdup(msg);
|
|
|
|
|
/* start our next search from the next ref */
|
|
|
|
|
hint = hint->next;
|
|
|
|
|
}
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int sideband_demux(int in, int out, void *data)
|
|
|
|
|
{
|
|
|
|
|
int *fd = data, ret;
|
|
|
|
|
#ifdef NO_PTHREADS
|
|
|
|
|
close(fd[1]);
|
|
|
|
|
#endif
|
|
|
|
|
ret = recv_sideband("send-pack", fd[0], out);
|
|
|
|
|
close(out);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int advertise_shallow_grafts_cb(const struct commit_graft *graft, void *cb)
|
|
|
|
|
{
|
|
|
|
|
struct strbuf *sb = cb;
|
|
|
|
|
if (graft->nr_parent == -1)
|
|
|
|
|
packet_buf_write(sb, "shallow %s\n", sha1_to_hex(graft->sha1));
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void advertise_shallow_grafts_buf(struct strbuf *sb)
|
|
|
|
|
{
|
|
|
|
|
if (!is_repository_shallow())
|
|
|
|
|
return;
|
|
|
|
|
for_each_commit_graft(advertise_shallow_grafts_cb, sb);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int ref_update_to_be_sent(const struct ref *ref, const struct send_pack_args *args)
|
|
|
|
|
{
|
|
|
|
|
if (!ref->peer_ref && !args->send_mirror)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
/* Check for statuses set by set_ref_status_for_push() */
|
|
|
|
|
switch (ref->status) {
|
|
|
|
|
case REF_STATUS_REJECT_NONFASTFORWARD:
|
|
|
|
|
case REF_STATUS_REJECT_ALREADY_EXISTS:
|
|
|
|
|
case REF_STATUS_REJECT_FETCH_FIRST:
|
|
|
|
|
case REF_STATUS_REJECT_NEEDS_FORCE:
|
|
|
|
|
case REF_STATUS_REJECT_STALE:
|
|
|
|
|
case REF_STATUS_REJECT_NODELETE:
|
|
|
|
|
case REF_STATUS_UPTODATE:
|
|
|
|
|
return 0;
|
|
|
|
|
default:
|
|
|
|
|
return 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>
10 years ago
|
|
|
/*
|
|
|
|
|
* the beginning of the next line, or the end of buffer.
|
|
|
|
|
*
|
|
|
|
|
* NEEDSWORK: perhaps move this to git-compat-util.h or somewhere and
|
|
|
|
|
* convert many similar uses found by "git grep -A4 memchr".
|
|
|
|
|
*/
|
|
|
|
|
static const char *next_line(const char *line, size_t len)
|
|
|
|
|
{
|
|
|
|
|
const char *nl = memchr(line, '\n', len);
|
|
|
|
|
if (!nl)
|
|
|
|
|
return line + len; /* incomplete line */
|
|
|
|
|
return nl + 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int generate_push_cert(struct strbuf *req_buf,
|
|
|
|
|
const struct ref *remote_refs,
|
|
|
|
|
struct send_pack_args *args,
|
|
|
|
|
const char *cap_string,
|
|
|
|
|
const char *push_cert_nonce)
|
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>
10 years ago
|
|
|
{
|
|
|
|
|
const struct ref *ref;
|
|
|
|
|
char *signing_key = xstrdup(get_signing_key());
|
|
|
|
|
const char *cp, *np;
|
|
|
|
|
struct strbuf cert = STRBUF_INIT;
|
|
|
|
|
int update_seen = 0;
|
|
|
|
|
|
|
|
|
|
strbuf_addf(&cert, "certificate version 0.1\n");
|
|
|
|
|
strbuf_addf(&cert, "pusher %s ", signing_key);
|
|
|
|
|
datestamp(&cert);
|
|
|
|
|
strbuf_addch(&cert, '\n');
|
|
|
|
|
if (args->url && *args->url) {
|
|
|
|
|
char *anon_url = transport_anonymize_url(args->url);
|
|
|
|
|
strbuf_addf(&cert, "pushee %s\n", anon_url);
|
|
|
|
|
free(anon_url);
|
|
|
|
|
}
|
|
|
|
|
if (push_cert_nonce[0])
|
|
|
|
|
strbuf_addf(&cert, "nonce %s\n", push_cert_nonce);
|
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>
10 years ago
|
|
|
strbuf_addstr(&cert, "\n");
|
|
|
|
|
|
|
|
|
|
for (ref = remote_refs; ref; ref = ref->next) {
|
|
|
|
|
if (!ref_update_to_be_sent(ref, args))
|
|
|
|
|
continue;
|
|
|
|
|
update_seen = 1;
|
|
|
|
|
strbuf_addf(&cert, "%s %s %s\n",
|
|
|
|
|
sha1_to_hex(ref->old_sha1),
|
|
|
|
|
sha1_to_hex(ref->new_sha1),
|
|
|
|
|
ref->name);
|
|
|
|
|
}
|
|
|
|
|
if (!update_seen)
|
|
|
|
|
goto free_return;
|
|
|
|
|
|
|
|
|
|
if (sign_buffer(&cert, &cert, signing_key))
|
|
|
|
|
die(_("failed to sign the push certificate"));
|
|
|
|
|
|
|
|
|
|
packet_buf_write(req_buf, "push-cert%c%s", 0, cap_string);
|
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>
10 years ago
|
|
|
for (cp = cert.buf; cp < cert.buf + cert.len; cp = np) {
|
|
|
|
|
np = next_line(cp, cert.buf + cert.len - cp);
|
|
|
|
|
packet_buf_write(req_buf,
|
|
|
|
|
"%.*s", (int)(np - cp), cp);
|
|
|
|
|
}
|
|
|
|
|
packet_buf_write(req_buf, "push-cert-end\n");
|
|
|
|
|
|
|
|
|
|
free_return:
|
|
|
|
|
free(signing_key);
|
|
|
|
|
strbuf_release(&cert);
|
|
|
|
|
return update_seen;
|
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>
10 years ago
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int send_pack(struct send_pack_args *args,
|
|
|
|
|
int fd[], struct child_process *conn,
|
|
|
|
|
struct ref *remote_refs,
|
|
|
|
|
struct sha1_array *extra_have)
|
|
|
|
|
{
|
|
|
|
|
int in = fd[0];
|
|
|
|
|
int out = fd[1];
|
|
|
|
|
struct strbuf req_buf = STRBUF_INIT;
|
|
|
|
|
struct strbuf cap_buf = STRBUF_INIT;
|
|
|
|
|
struct ref *ref;
|
|
|
|
|
int need_pack_data = 0;
|
|
|
|
|
int allow_deleting_refs = 0;
|
|
|
|
|
int status_report = 0;
|
|
|
|
|
int use_sideband = 0;
|
|
|
|
|
int quiet_supported = 0;
|
|
|
|
|
int agent_supported = 0;
|
|
|
|
|
unsigned cmds_sent = 0;
|
|
|
|
|
int ret;
|
|
|
|
|
struct async demux;
|
|
|
|
|
const char *push_cert_nonce = NULL;
|
|
|
|
|
|
|
|
|
|
/* Does the other end support the reporting? */
|
|
|
|
|
if (server_supports("report-status"))
|
|
|
|
|
status_report = 1;
|
|
|
|
|
if (server_supports("delete-refs"))
|
|
|
|
|
allow_deleting_refs = 1;
|
|
|
|
|
if (server_supports("ofs-delta"))
|
|
|
|
|
args->use_ofs_delta = 1;
|
|
|
|
|
if (server_supports("side-band-64k"))
|
|
|
|
|
use_sideband = 1;
|
|
|
|
|
if (server_supports("quiet"))
|
|
|
|
|
quiet_supported = 1;
|
|
|
|
|
if (server_supports("agent"))
|
|
|
|
|
agent_supported = 1;
|
|
|
|
|
if (server_supports("no-thin"))
|
|
|
|
|
args->use_thin_pack = 0;
|
|
|
|
|
if (args->push_cert) {
|
|
|
|
|
int len;
|
|
|
|
|
|
|
|
|
|
push_cert_nonce = server_feature_value("push-cert", &len);
|
|
|
|
|
if (!push_cert_nonce)
|
|
|
|
|
die(_("the receiving end does not support --signed push"));
|
|
|
|
|
push_cert_nonce = xmemdupz(push_cert_nonce, len);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!remote_refs) {
|
|
|
|
|
fprintf(stderr, "No refs in common and none specified; doing nothing.\n"
|
|
|
|
|
"Perhaps you should specify a branch such as 'master'.\n");
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (status_report)
|
|
|
|
|
strbuf_addstr(&cap_buf, " report-status");
|
|
|
|
|
if (use_sideband)
|
|
|
|
|
strbuf_addstr(&cap_buf, " side-band-64k");
|
|
|
|
|
if (quiet_supported && (args->quiet || !args->progress))
|
|
|
|
|
strbuf_addstr(&cap_buf, " quiet");
|
|
|
|
|
if (agent_supported)
|
|
|
|
|
strbuf_addf(&cap_buf, " agent=%s", git_user_agent_sanitized());
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* NEEDSWORK: why does delete-refs have to be so specific to
|
|
|
|
|
* send-pack machinery that set_ref_status_for_push() cannot
|
|
|
|
|
* set this bit for us???
|
|
|
|
|
*/
|
|
|
|
|
for (ref = remote_refs; ref; ref = ref->next)
|
|
|
|
|
if (ref->deletion && !allow_deleting_refs)
|
|
|
|
|
ref->status = REF_STATUS_REJECT_NODELETE;
|
|
|
|
|
|
|
|
|
|
if (!args->dry_run)
|
|
|
|
|
advertise_shallow_grafts_buf(&req_buf);
|
|
|
|
|
|
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>
10 years ago
|
|
|
if (!args->dry_run && args->push_cert)
|
|
|
|
|
cmds_sent = generate_push_cert(&req_buf, remote_refs, args,
|
|
|
|
|
cap_buf.buf, push_cert_nonce);
|
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>
10 years ago
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Clear the status for each ref and see if we need to send
|
|
|
|
|
* the pack data.
|
|
|
|
|
*/
|
|
|
|
|
for (ref = remote_refs; ref; ref = ref->next) {
|
|
|
|
|
if (!ref_update_to_be_sent(ref, args))
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
if (!ref->deletion)
|
|
|
|
|
need_pack_data = 1;
|
|
|
|
|
|
|
|
|
|
if (args->dry_run || !status_report)
|
|
|
|
|
ref->status = REF_STATUS_OK;
|
|
|
|
|
else
|
|
|
|
|
ref->status = REF_STATUS_EXPECTING_REPORT;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Finally, tell the other end!
|
|
|
|
|
*/
|
|
|
|
|
for (ref = remote_refs; ref; ref = ref->next) {
|
|
|
|
|
char *old_hex, *new_hex;
|
|
|
|
|
|
|
|
|
|
if (args->dry_run || args->push_cert)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
if (!ref_update_to_be_sent(ref, args))
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
old_hex = sha1_to_hex(ref->old_sha1);
|
|
|
|
|
new_hex = sha1_to_hex(ref->new_sha1);
|
|
|
|
|
if (!cmds_sent) {
|
|
|
|
|
packet_buf_write(&req_buf,
|
|
|
|
|
"%s %s %s%c%s",
|
|
|
|
|
old_hex, new_hex, ref->name, 0,
|
|
|
|
|
cap_buf.buf);
|
|
|
|
|
cmds_sent = 1;
|
|
|
|
|
} else {
|
|
|
|
|
packet_buf_write(&req_buf, "%s %s %s",
|
|
|
|
|
old_hex, new_hex, ref->name);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (args->stateless_rpc) {
|
|
|
|
|
if (!args->dry_run && (cmds_sent || is_repository_shallow())) {
|
|
|
|
|
packet_buf_flush(&req_buf);
|
|
|
|
|
send_sideband(out, -1, req_buf.buf, req_buf.len, LARGE_PACKET_MAX);
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
write_or_die(out, req_buf.buf, req_buf.len);
|
|
|
|
|
packet_flush(out);
|
|
|
|
|
}
|
|
|
|
|
strbuf_release(&req_buf);
|
|
|
|
|
strbuf_release(&cap_buf);
|
|
|
|
|
|
|
|
|
|
if (use_sideband && cmds_sent) {
|
|
|
|
|
memset(&demux, 0, sizeof(demux));
|
|
|
|
|
demux.proc = sideband_demux;
|
|
|
|
|
demux.data = fd;
|
|
|
|
|
demux.out = -1;
|
|
|
|
|
if (start_async(&demux))
|
|
|
|
|
die("send-pack: unable to fork off sideband demultiplexer");
|
|
|
|
|
in = demux.out;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (need_pack_data && cmds_sent) {
|
|
|
|
|
if (pack_objects(out, remote_refs, extra_have, args) < 0) {
|
|
|
|
|
for (ref = remote_refs; ref; ref = ref->next)
|
|
|
|
|
ref->status = REF_STATUS_NONE;
|
|
|
|
|
if (args->stateless_rpc)
|
|
|
|
|
close(out);
|
|
|
|
|
if (git_connection_is_socket(conn))
|
|
|
|
|
shutdown(fd[0], SHUT_WR);
|
|
|
|
|
if (use_sideband)
|
|
|
|
|
finish_async(&demux);
|
|
|
|
|
fd[1] = -1;
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
if (!args->stateless_rpc)
|
|
|
|
|
/* Closed by pack_objects() via start_command() */
|
|
|
|
|
fd[1] = -1;
|
|
|
|
|
}
|
|
|
|
|
if (args->stateless_rpc && cmds_sent)
|
|
|
|
|
packet_flush(out);
|
|
|
|
|
|
|
|
|
|
if (status_report && cmds_sent)
|
|
|
|
|
ret = receive_status(in, remote_refs);
|
|
|
|
|
else
|
|
|
|
|
ret = 0;
|
|
|
|
|
if (args->stateless_rpc)
|
|
|
|
|
packet_flush(out);
|
|
|
|
|
|
|
|
|
|
if (use_sideband && cmds_sent) {
|
|
|
|
|
if (finish_async(&demux)) {
|
|
|
|
|
error("error in sideband demultiplexer");
|
|
|
|
|
ret = -1;
|
|
|
|
|
}
|
|
|
|
|
close(demux.out);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (ret < 0)
|
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
|
|
if (args->porcelain)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
for (ref = remote_refs; ref; ref = ref->next) {
|
|
|
|
|
switch (ref->status) {
|
|
|
|
|
case REF_STATUS_NONE:
|
|
|
|
|
case REF_STATUS_UPTODATE:
|
|
|
|
|
case REF_STATUS_OK:
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
