summaryrefslogtreecommitdiff
path: root/Documentation/technical/pack-protocol.txt
diff options
context:
space:
mode:
authorJonathan Tan <jonathantanmy@google.com>2017-05-09 19:23:53 (GMT)
committerJunio C Hamano <gitster@pobox.com>2017-05-10 04:18:28 (GMT)
commitcbaf82cc6b734244a9190c3341ca5f08f8d5acc4 (patch)
treeb06badfc81d2b16f22715a4f8b33dc40523a6719 /Documentation/technical/pack-protocol.txt
parentb7b744f297b736c51636407f5883b3777bb36433 (diff)
downloadgit-cbaf82cc6b734244a9190c3341ca5f08f8d5acc4.zip
git-cbaf82cc6b734244a9190c3341ca5f08f8d5acc4.tar.gz
git-cbaf82cc6b734244a9190c3341ca5f08f8d5acc4.tar.bz2
receive-pack: verify push options in cert
In commit f6a4e61 ("push: accept push options", 2016-07-14), send-pack was taught to include push options both within the signed cert (if the push is a signed push) and outside the signed cert; however, receive-pack ignores push options within the cert, only handling push options outside the cert. Teach receive-pack, in the case that push options are provided for a signed push, to verify that the push options both within the cert and outside the cert are consistent. This sets in stone the requirement that send-pack redundantly send its push options in 2 places, but I think that this is better than the alternatives. Sending push options only within the cert is backwards-incompatible with existing Git servers (which read push options only from outside the cert), and sending push options only outside the cert means that the push options are not signed for. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation/technical/pack-protocol.txt')
-rw-r--r--Documentation/technical/pack-protocol.txt32
1 files changed, 26 insertions, 6 deletions
diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt
index c59ac99..d7358f7 100644
--- a/Documentation/technical/pack-protocol.txt
+++ b/Documentation/technical/pack-protocol.txt
@@ -468,13 +468,10 @@ that it wants to update, it sends a line listing the obj-id currently on
the server, the obj-id the client would like to update it to and the name
of the reference.
-This list is followed by a flush-pkt. Then the push options are transmitted
-one per packet followed by another flush-pkt. After that the packfile that
-should contain all the objects that the server will need to complete the new
-references will be sent.
+This list is followed by a flush-pkt.
----
- update-request = *shallow ( command-list | push-cert ) [packfile]
+ update-requests = *shallow ( command-list | push-cert )
shallow = PKT-LINE("shallow" SP obj-id)
@@ -495,12 +492,35 @@ references will be sent.
PKT-LINE("pusher" SP ident LF)
PKT-LINE("pushee" SP url LF)
PKT-LINE("nonce" SP nonce LF)
+ *PKT-LINE("push-option" SP push-option LF)
PKT-LINE(LF)
*PKT-LINE(command LF)
*PKT-LINE(gpg-signature-lines LF)
PKT-LINE("push-cert-end" LF)
- packfile = "PACK" 28*(OCTET)
+ push-option = 1*( VCHAR | SP )
+----
+
+If the server has advertised the 'push-options' capability and the client has
+specified 'push-options' as part of the capability list above, the client then
+sends its push options followed by a flush-pkt.
+
+----
+ push-options = *PKT-LINE(push-option) flush-pkt
+----
+
+For backwards compatibility with older Git servers, if the client sends a push
+cert and push options, it MUST send its push options both embedded within the
+push cert and after the push cert. (Note that the push options within the cert
+are prefixed, but the push options after the cert are not.) Both these lists
+MUST be the same, modulo the prefix.
+
+After that the packfile that
+should contain all the objects that the server will need to complete the new
+references will be sent.
+
+----
+ packfile = "PACK" 28*(OCTET)
----
If the receiving end does not support delete-refs, the sending end MUST