summaryrefslogtreecommitdiff
path: root/Documentation/technical/protocol-capabilities.txt
diff options
context:
space:
mode:
authorJunio C Hamano <gitster@pobox.com>2014-08-18 21:38:45 (GMT)
committerJunio C Hamano <gitster@pobox.com>2014-09-15 20:23:28 (GMT)
commit4adf569dea052dac88121d822e11c249986b3398 (patch)
tree5394494825d8283628dce7efa1b07320b8db1e25 /Documentation/technical/protocol-capabilities.txt
parent20a7558f31e44e26ddbb8aa55bfd9316a6b67f82 (diff)
downloadgit-4adf569dea052dac88121d822e11c249986b3398.zip
git-4adf569dea052dac88121d822e11c249986b3398.tar.gz
git-4adf569dea052dac88121d822e11c249986b3398.tar.bz2
signed push: remove duplicated protocol info
With the interim protocol, we used to send the update commands even though we already send a signed copy of the same information when push certificate is in use. Update the send-pack/receive-pack pair not to do so. The notable thing on the receive-pack side is that it makes sure that there is no command sent over the traditional protocol packet outside the push certificate. Otherwise a pusher can claim to be pushing one set of ref updates in the signed certificate while issuing commands to update unrelated refs, and such an update will evade later audits. Finally, start documenting the protocol. Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation/technical/protocol-capabilities.txt')
-rw-r--r--Documentation/technical/protocol-capabilities.txt12
1 files changed, 10 insertions, 2 deletions
diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt
index e174343..a478cc4 100644
--- a/Documentation/technical/protocol-capabilities.txt
+++ b/Documentation/technical/protocol-capabilities.txt
@@ -18,8 +18,8 @@ was sent. Server MUST NOT ignore capabilities that client requested
and server advertised. As a consequence of these rules, server MUST
NOT advertise capabilities it does not understand.
-The 'report-status', 'delete-refs', and 'quiet' capabilities are sent and
-recognized by the receive-pack (push to server) process.
+The 'report-status', 'delete-refs', 'quiet', and 'push-cert' capabilities
+are sent and recognized by the receive-pack (push to server) process.
The 'ofs-delta' and 'side-band-64k' capabilities are sent and recognized
by both upload-pack and receive-pack protocols. The 'agent' capability
@@ -250,3 +250,11 @@ allow-tip-sha1-in-want
If the upload-pack server advertises this capability, fetch-pack may
send "want" lines with SHA-1s that exist at the server but are not
advertised by upload-pack.
+
+push-cert
+---------
+
+The receive-pack server that advertises this capability is willing
+to accept a signed push certificate. A send-pack client MUST NOT
+send a push-cert packet unless the receive-pack server advertises
+this capability.