From a85b377d0419a9dfaca8af2320cc33b051cbed04 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Fri, 12 Sep 2014 11:17:07 -0700 Subject: 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 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 --- send-pack.h | 1 + 1 file changed, 1 insertion(+) (limited to 'send-pack.h') diff --git a/send-pack.h b/send-pack.h index 8e843924cf..3555d8e8ad 100644 --- a/send-pack.h +++ b/send-pack.h @@ -11,6 +11,7 @@ struct send_pack_args { use_thin_pack:1, use_ofs_delta:1, dry_run:1, + push_cert:1, stateless_rpc:1; }; -- cgit 1.2.3-korg From 9be89160e7382a88e56a02bcf38f4694dd6542d6 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Fri, 22 Aug 2014 18:15:24 -0700 Subject: signed push: add "pushee" header to push certificate Record the URL of the intended recipient for a push (after anonymizing it if it has authentication material) on a new "pushee URL" header. Because the networking configuration (SSH-tunnels, proxies, etc.) on the pushing user's side varies, the receiving repository may not know the single canonical URL all the pushing users would refer it as (besides, many sites allow pushing over ssh://host/path and https://host/path protocols to the same repository but with different local part of the path). So this value may not be reliably used for replay-attack prevention purposes, but this will still serve as a human readable hint to identify the repository the certificate refers to. Signed-off-by: Junio C Hamano --- Documentation/technical/pack-protocol.txt | 6 ++++++ send-pack.c | 5 +++++ send-pack.h | 1 + transport.c | 1 + 4 files changed, 13 insertions(+) (limited to 'send-pack.h') diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt index 4a5c2e8636..7b543dc311 100644 --- a/Documentation/technical/pack-protocol.txt +++ b/Documentation/technical/pack-protocol.txt @@ -484,6 +484,7 @@ references. push-cert = PKT-LINE("push-cert" NUL capability-list LF) PKT-LINE("certificate version 0.1" LF) PKT-LINE("pusher" SP ident LF) + PKT-LINE("pushee" SP url LF) PKT-LINE(LF) *PKT-LINE(command LF) *PKT-LINE(gpg-signature-lines LF) @@ -527,6 +528,11 @@ Currently, the following header fields are defined: Identify the GPG key in "Human Readable Name " format. +`pushee` url:: + The repository URL (anonymized, if the URL contains + authentication material) the user who ran `git push` + intended to push into. + The GPG signature lines are a detached signature for the contents recorded in the push certificate before the signature block begins. The detached signature is used to certify that the commands were diff --git a/send-pack.c b/send-pack.c index 857beb393d..9c2c64966d 100644 --- a/send-pack.c +++ b/send-pack.c @@ -240,6 +240,11 @@ static int generate_push_cert(struct strbuf *req_buf, datestamp(stamp, sizeof(stamp)); strbuf_addf(&cert, "certificate version 0.1\n"); strbuf_addf(&cert, "pusher %s %s\n", signing_key, stamp); + if (args->url && *args->url) { + char *anon_url = transport_anonymize_url(args->url); + strbuf_addf(&cert, "pushee %s\n", anon_url); + free(anon_url); + } strbuf_addstr(&cert, "\n"); for (ref = remote_refs; ref; ref = ref->next) { diff --git a/send-pack.h b/send-pack.h index 3555d8e8ad..5635457746 100644 --- a/send-pack.h +++ b/send-pack.h @@ -2,6 +2,7 @@ #define SEND_PACK_H struct send_pack_args { + const char *url; unsigned verbose:1, quiet:1, porcelain:1, diff --git a/transport.c b/transport.c index 07fdf86494..1df13753a6 100644 --- a/transport.c +++ b/transport.c @@ -827,6 +827,7 @@ static int git_transport_push(struct transport *transport, struct ref *remote_re args.dry_run = !!(flags & TRANSPORT_PUSH_DRY_RUN); args.porcelain = !!(flags & TRANSPORT_PUSH_PORCELAIN); args.push_cert = !!(flags & TRANSPORT_PUSH_CERT); + args.url = transport->url; ret = send_pack(&args, data->fd, data->conn, remote_refs, &data->extra_have); -- cgit 1.2.3-korg