From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Subject: [PATCH v2 00/19] Signed push
Date: Fri, 22 Aug 2014 13:30:05 -0700 [thread overview]
Message-ID: <1408739424-31429-1-git-send-email-gitster@pobox.com> (raw)
The first round is found at $gmane/255520
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.
This series introduces a cryptographic assurance for ref updates
done by "git push" by introducing a mechanism that allows you to
sign a "push certificate" (for the lack of better name) every time
you push. Think of it as working on an axis orthogonal to the
traditional "signed tags".
Notable changes from the first iteration are:
- "push --signed" against a receiver that does not support push
certificates used to downgrade to an unsigned push with a
warning; this round makes it die.
- The push-cert capability the receiver sends now with a value,
<nonce>; the certificate must include this value on the "nonce"
header to prevent a valid push certificate that was used to push
elsewhere from being replayed to push to an unrelated repository.
And several typofixes here and there.
Junio C Hamano (19):
receive-pack: do not overallocate command structure
receive-pack: parse feature request a bit earlier
receive-pack: do not reuse old_sha1[] for other things
receive-pack: factor out queueing of command
send-pack: move REF_STATUS_REJECT_NODELETE logic a bit higher
send-pack: refactor decision to send update per ref
send-pack: always send capabilities
send-pack: factor out capability string generation
send-pack: rename "new_refs" to "need_pack_data"
send-pack: refactor inspecting and resetting status and sending
commands
send-pack: clarify that cmds_sent is a boolean
gpg-interface: move parse_gpg_output() to where it should be
gpg-interface: move parse_signature() to where it should be
pack-protocol doc: typofix for PKT-LINE
the beginning of the signed push
receive-pack: GPG-validate push certificates
send-pack: send feature request on push-cert packet
signed push: signed push: remove duplicated protocol info
signed push: fortify against replay attacks
Documentation/git-push.txt | 9 +-
Documentation/git-receive-pack.txt | 41 ++++-
Documentation/technical/pack-protocol.txt | 25 ++-
Documentation/technical/protocol-capabilities.txt | 13 +-
builtin/push.c | 1 +
builtin/receive-pack.c | 199 ++++++++++++++++++----
commit.c | 36 ----
gpg-interface.c | 57 +++++++
gpg-interface.h | 18 +-
send-pack.c | 197 ++++++++++++++++-----
send-pack.h | 1 +
t/t5534-push-signed.sh | 82 +++++++++
tag.c | 20 ---
tag.h | 1 -
transport.c | 4 +
transport.h | 5 +
16 files changed, 564 insertions(+), 145 deletions(-)
create mode 100755 t/t5534-push-signed.sh
--
2.1.0-304-g950f846
next reply other threads:[~2014-08-22 20:30 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-22 20:30 Junio C Hamano [this message]
2014-08-22 20:30 ` [PATCH v2 01/19] receive-pack: do not overallocate command structure Junio C Hamano
2014-08-22 20:30 ` [PATCH v2 02/19] receive-pack: parse feature request a bit earlier Junio C Hamano
2014-08-22 20:30 ` [PATCH v2 03/19] receive-pack: do not reuse old_sha1[] for other things Junio C Hamano
2014-08-22 20:30 ` [PATCH v2 04/19] receive-pack: factor out queueing of command Junio C Hamano
2014-08-22 20:30 ` [PATCH v2 05/19] send-pack: move REF_STATUS_REJECT_NODELETE logic a bit higher Junio C Hamano
2014-08-22 20:30 ` [PATCH v2 06/19] send-pack: refactor decision to send update per ref Junio C Hamano
2014-08-22 20:30 ` [PATCH v2 07/19] send-pack: always send capabilities Junio C Hamano
2014-08-22 20:30 ` [PATCH v2 08/19] send-pack: factor out capability string generation Junio C Hamano
2014-08-22 20:30 ` [PATCH v2 09/19] send-pack: rename "new_refs" to "need_pack_data" Junio C Hamano
2014-08-22 20:30 ` [PATCH v2 10/19] send-pack: refactor inspecting and resetting status and sending commands Junio C Hamano
2014-08-22 20:30 ` [PATCH v2 11/19] send-pack: clarify that cmds_sent is a boolean Junio C Hamano
2014-08-22 20:30 ` [PATCH v2 12/19] gpg-interface: move parse_gpg_output() to where it should be Junio C Hamano
2014-08-22 20:30 ` [PATCH v2 13/19] gpg-interface: move parse_signature() " Junio C Hamano
2014-08-22 20:30 ` [PATCH v2 14/19] pack-protocol doc: typofix for PKT-LINE Junio C Hamano
2014-08-22 20:30 ` [PATCH v2 15/19] the beginning of the signed push Junio C Hamano
2014-08-22 20:30 ` [PATCH v2 16/19] receive-pack: GPG-validate push certificates Junio C Hamano
2014-08-22 20:30 ` [PATCH v2 17/19] send-pack: send feature request on push-cert packet Junio C Hamano
2014-08-22 20:30 ` [PATCH v2 18/19] signed push: remove duplicated protocol info Junio C Hamano
2014-08-22 20:30 ` [PATCH v2 19/19] signed push: fortify against replay attacks Junio C Hamano
2014-08-24 3:29 ` Eric Sunshine
2014-08-30 11:59 ` Stefan Beller
2014-09-02 17:40 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1408739424-31429-1-git-send-email-gitster@pobox.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).