document signature formats
cover document signature formats
This is a first shot at documenting the various signatures that we use in a technical document. If something like this is deemed useful I should probably recreate the sample signatures using our testlib keys and users in a v2.
Michael J Gruber (2):
Documentation/technical: signature formats Documentation/technical: document push certificate format
Documentation/Makefile | 1 + Documentation/technical/signature-format.txt | 161 +++++++++++++++++++++++++++ 2 files changed, 162 insertions(+) create mode 100644 Documentation/technical/signature-format.txt
Signature · 1 line
2.1.2.756.gfa53a0a
PATCH 1/2 Documentation/technical: signature formats
Various formats for storing signatures have accumulated by now. Document them to keep track (and maybe avoid yet another one).
--- Documentation/Makefile | 1 + Documentation/technical/signature-format.txt | 126 +++++++++++++++++++++++++++ 2 files changed, 127 insertions(+) create mode 100644 Documentation/technical/signature-format.txt
Documentation/Makefile +1 -0
@@ -74,6 +74,7 @@ TECH_DOCS += technical/protocol-common TECH_DOCS += technical/racy-git TECH_DOCS += technical/send-pack-pipeline TECH_DOCS += technical/shallow +TECH_DOCS += technical/signature-format TECH_DOCS += technical/trivial-merge SP_ARTICLES += $(TECH_DOCS) SP_ARTICLES += technical/api-index
Documentation/technical/signature-format.txt new file +126 -0
126 lines not on this page · raw message
Signature · 1 line
2.1.2.756.gfa53a0a
Re: [PATCH 1/2] Documentation/technical: signature formats
Documentation/technical/signature-format.txt line 55
Quoted 7 lines · Michael J Gruber
+== Commit signature
Documentation/technical/signature-format.txt new file +6
-0+ +- created by: `git commit -s` +- payload: commit object +- embedding: header entry `gpgsig` + (content is preceded by a space) +- example: commit with commit message `sigtest`
Actually it is not "content is preceded by space", but it is multi-line header which uses RFC-2822 like wrapping (see "Long Header Fields" there) - leading space means wrapped in email, separate line here.
Nice work.
Signature · 1 line
Jakub Narębski
Re: [PATCH 1/2] Documentation/technical: signature formats
In reply to Michael J GruberQuoted 2 lines · Michael J Gruber
Various formats for storing signatures have accumulated by now. Document them to keep track (and maybe avoid yet another one).
I haven't looked at the description closely, but it is a good thing to describe signature in a tag and in a commit in detail, which we failed to do so far.
The principle is essentially the same between the signature on a tag and on a commit: a detached PGP signature over the remainder of the object data is created, and then the signature is inserted into an appropriate place in the resulting object. That "appropriate place" is influenced by the type and nature of the object.
A mergetag is not fundamentally a "signature" in the above sense, though. It is just a dump of the object content in a regular object header field (hence indented by one SP), and its contents having PGP SIGNATURE is merely a natural consequence of the object recorded being a signed tag. So the description of it in the same place as description for signed tags and signed commits feels a little bit out of place, but I do not think of a better place to describe it.
Thanks.
Quoted 152 lines
Signed-off-by Michael J Gruber <[email protected]>--- Documentation/Makefile | 1 + Documentation/technical/signature-format.txt | 126 +++++++++++++++++++++++++++ 2 files changed, 127 insertions(+) create mode 100644 Documentation/technical/signature-format.txtDocumentation/Makefile +1
-0@@ -74,6 +74,7 @@ TECH_DOCS += technical/protocol-common TECH_DOCS += technical/racy-git TECH_DOCS += technical/send-pack-pipeline TECH_DOCS += technical/shallow +TECH_DOCS += technical/signature-format TECH_DOCS += technical/trivial-merge SP_ARTICLES += $(TECH_DOCS) SP_ARTICLES += technical/api-indexDocumentation/technical/signature-format.txt new file +126
-0@@ -0,0 +1,126 @@ +Git signature format +==================== + +== Overview + +Git uses cryptographic signatures in various places, currently +objects (tags, commits, mergetags) and transactions (pushes). +In every case, the command which is about to create an object or +transaction determines a payload from that, calls gpg to obtain +a detached signature for the payload and embeds the signature +into the object or transaction. + +Signatures always begin with `-----BEGIN PGP SIGNATURE-----` +and end with `-----END PGP SIGNATURE-----`. + +== Tag signatures + +- created by: `git tag -s` +- payload: annotated tag object +- embedding: append the signature to the tag object +- example: tag `stag` with tag message `tagmess` + +---- +object 8cbad082a020b7d4ef729b14e1a654c4f60791c6 +type commit +tag stag +tagger Michael J Gruber <[email protected]> 1351067460 +0200 + +tagmess +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.4.12 (GNU/Linux) + +iQIcBAABCgAGBQJQh6dPAAoJELR76rQkz552ZBEP/3vkpftZnhsUkGhqXXptnRhz +5A3n+BqFTsh4d4C15lcRcevwTyyQF61vrFKFRE7Cl5XVqVHowW0al+Dx7j5p35Mz +PqBZUbEkBFc9xY8WasQYbJl5yDboc8Ora71SEJ1k59duETXmZ67ISpEe6HF3d2xK +3BGfqaBMwU+Aql0pDMtysoOgEgs7d/Vin9gIXJcqAvw71bpNyZvFUln3do2eLC/v +VW0bVvAN3B66fLx3li8hEZ4wfrg0Uui5zSN95+uc2DUGW03BNR/sKhYXstHAoqef +4WIAD70e+9vArh8WqPTIUWl0w+1ixgVvGckHXHW10MdwkoVtwo4tawRxngLBKuI9 +pUu7dc/TIVl15z/y1EmQ25rB4WV9M9W+uRauUi/T3c0hfSuZkB6B1tCu3QStPbWz +AK3O6Neoni2NgMDLmrWzgDZA3Z/+h9RBV/kNda0RpbWZYJOJILBR+Q8+BZOwDZX/ +hu/tITC7IHVJgMXYGlEFybEn/clbtLsZr8zLlSZyropl0mvUBLeBCrjYBQuDN86g +yew/Tzs9T5MEFagUkbRERz5rP5OIE9XpXcHMsZve7cCL3YQy0LOkZk3RZKUsbv8g +MVU1px5/ImBkr0MU0XZxstsAV0YPiON3+qMOnrdGuFx11YQi6cmIA2eww2KPqzHY +YKirAGNintaD8yXAlwLd +=wF8p +-----END PGP SIGNATURE----- +---- + +== Commit signature + +- created by: `git commit -s` +- payload: commit object +- embedding: header entry `gpgsig` + (content is preceded by a space) +- example: commit with commit message `sigtest` + +---- +tree 14461762125c079e55a9684ae3a96e27de5b3f2f +parent da19995926ec89e48297a3163b0f5190af3a8650 +author Michael J Gruber <[email protected]> 1325088101 +0100 +committer Michael J Gruber <[email protected]> 1325088101 +0100 +gpgsig -----BEGIN PGP SIGNATURE----- + Version: GnuPG v1.4.11 (GNU/Linux) + + iQIcBAABCgAGBQJO+z1lAAoJELR76rQkz552xOoQAJgV6sstR8cge760X7awb00V + svN+pcc1TtJZecYWakCIe6dGPAK2Yk1AwExV0tbAQskPxYIqwnuysXHvVlmyJh5P + 1N033YSRc8j59YNQNaLIAh6+c59cKcZdWQyrA1HFVWGqoafCD2+nMglb/JbN9jqQ + 5gsxfFGoE0blT+BnMrchzPL4kjMJQBszV5ccATu3iIgSv23p5rA4tm3/P44enIsH + U9nYODlKmzsAulThQoSd4Qk0MNIg86MjIXanPkj4S+TLLgDa6Zf8W3m28IiRwPF1 + WemWpQ9VwSSHKuGVyHGG2OErtDDftILcYtjW5c/UnLw38hWPwc+KxVmAdEBY3vgk + OACDEDLqAWgc4rLdWgkoxieIi0aKN+iN4kogbEtSl4VzgvX0iGLZP8cyJnGxHria + Qz2UcesNqVPPqOxsIJKpr3CByrh2WDzH8W3tvGuy5q8EsTx5uF1HGoYb3PIx76QG + 3ClhL5Wtjk3/iQnycWo60eKMJccLbv+uoXzUP3LA0prt0K3a+52pWVppt8RW1L6u + kALJjsc44gr04v/fo5x6zkgFFt+8e/YWDZO+vwCJDmCyqggEvA5dj6i0y2B+hZjL + RVG0RATLroPgMa6oHSEVEbP+Ui4JZ3k3fRLIOupb0qjHtv/cvB7kcXevpdQUFGs0 + 6kmaMJBcWutA6HrosuP/ + =9PhX + -----END PGP SIGNATURE----- + +sigtest +---- + +== Mergetag signature + +- created by: `git merge` on signed tag +- payload/embedding: the whole signed tag object is embedded into + the (merge) commit object of header entry `mergetag` +- example: merge of the signed tag `stag` as above + +---- +tree ceb2177fea91ec9369e012dbe794419ee0731ce7 +parent 9c20ba82367dab0fe4789e2be400a7fb0c447c34 +parent 8cbad082a020b7d4ef729b14e1a654c4f60791c6 +author Michael J Gruber <[email protected]> 1412951117 +0200 +committer Michael J Gruber <[email protected]> 1412951117 +0200 +mergetag object 8cbad082a020b7d4ef729b14e1a654c4f60791c6 + type commit + tag stag + tagger Michael J Gruber <[email protected]> 1351067460 +0200 + + tagmess + -----BEGIN PGP SIGNATURE----- + Version: GnuPG v1.4.12 (GNU/Linux) + + iQIcBAABCgAGBQJQh6dPAAoJELR76rQkz552ZBEP/3vkpftZnhsUkGhqXXptnRhz + 5A3n+BqFTsh4d4C15lcRcevwTyyQF61vrFKFRE7Cl5XVqVHowW0al+Dx7j5p35Mz + PqBZUbEkBFc9xY8WasQYbJl5yDboc8Ora71SEJ1k59duETXmZ67ISpEe6HF3d2xK + 3BGfqaBMwU+Aql0pDMtysoOgEgs7d/Vin9gIXJcqAvw71bpNyZvFUln3do2eLC/v + VW0bVvAN3B66fLx3li8hEZ4wfrg0Uui5zSN95+uc2DUGW03BNR/sKhYXstHAoqef + 4WIAD70e+9vArh8WqPTIUWl0w+1ixgVvGckHXHW10MdwkoVtwo4tawRxngLBKuI9 + pUu7dc/TIVl15z/y1EmQ25rB4WV9M9W+uRauUi/T3c0hfSuZkB6B1tCu3QStPbWz + AK3O6Neoni2NgMDLmrWzgDZA3Z/+h9RBV/kNda0RpbWZYJOJILBR+Q8+BZOwDZX/ + hu/tITC7IHVJgMXYGlEFybEn/clbtLsZr8zLlSZyropl0mvUBLeBCrjYBQuDN86g + yew/Tzs9T5MEFagUkbRERz5rP5OIE9XpXcHMsZve7cCL3YQy0LOkZk3RZKUsbv8g + MVU1px5/ImBkr0MU0XZxstsAV0YPiON3+qMOnrdGuFx11YQi6cmIA2eww2KPqzHY + YKirAGNintaD8yXAlwLd + =wF8p + -----END PGP SIGNATURE----- + +Merge tag 'stag' into HEAD + +tagmess + +Conflicts: + ... +----
Re: [PATCH 1/2] Documentation/technical: signature formats
Junio C Hamano schrieb am 22.10.2014 um 21:02:
Quoted 9 lines
Quoted 2 lines · Michael J Gruber
Various formats for storing signatures have accumulated by now. Document them to keep track (and maybe avoid yet another one).
I haven't looked at the description closely, but it is a good thing to describe signature in a tag and in a commit in detail, which we failed to do so far.
Quoted 5 lines
The principle is essentially the same between the signature on a tag and on a commit: a detached PGP signature over the remainder of the object data is created, and then the signature is inserted into an appropriate place in the resulting object. That "appropriate place" is influenced by the type and nature of the object.
Yes, the detached signature can't easily be appended to a commit object the way it follows a tag object. Conversely, signed tag could easily look like signed commits do (sig in header), but that would require a migration procedure.
Quoted 7 lines
A mergetag is not fundamentally a "signature" in the above sense, though. It is just a dump of the object content in a regular object header field (hence indented by one SP), and its contents having PGP SIGNATURE is merely a natural consequence of the object recorded being a signed tag. So the description of it in the same place as description for signed tags and signed commits feels a little bit out of place, but I do not think of a better place to describe it.
I guess referencing the tag object (like other objects do) rather than embedding it would have had its merits, but that is beating up a dead horse. On the other hand, we could migrate to "mergetag sha1" rather than "mergetag object foo" which is easily distinguished, but only embedded objects are "safe" against non-aware gits.
Quoted 1 line
Thanks.
Thanks, Jakub and Junio.
I will correct the wording for the multiline header and put the mergetag last to make it clearer that it's related but different.
Michael
Re: [PATCH 1/2] Documentation/technical: signature formats
Quoted 16 lines · Michael J Gruber
Junio C Hamano schrieb am 22.10.2014 um 21:02:
Quoted 9 lines
Quoted 2 lines · Michael J Gruber
Various formats for storing signatures have accumulated by now. Document them to keep track (and maybe avoid yet another one).
I haven't looked at the description closely, but it is a good thing to describe signature in a tag and in a commit in detail, which we failed to do so far.
Quoted 5 lines
The principle is essentially the same between the signature on a tag and on a commit: a detached PGP signature over the remainder of the object data is created, and then the signature is inserted into an appropriate place in the resulting object. That "appropriate place" is influenced by the type and nature of the object.
Quoted 4 lines
Yes, the detached signature can't easily be appended to a commit object the way it follows a tag object. Conversely, signed tag could easily look like signed commits do (sig in header), but that would require a migration procedure.
I do not see much point in doing such "migration", though. Whom is it supposed to help?
Quoted 11 lines
Quoted 7 lines
A mergetag is not fundamentally a "signature" in the above sense, though. It is just a dump of the object content in a regular object header field (hence indented by one SP), and its contents having PGP SIGNATURE is merely a natural consequence of the object recorded being a signed tag. So the description of it in the same place as description for signed tags and signed commits feels a little bit out of place, but I do not think of a better place to describe it.
I guess referencing the tag object (like other objects do) rather than embedding it would have had its merits, but that is beating up a dead horse.
Such a format would have defeated a major point of mergetag. The header embeds the data, not a reference to an external object, so that the resulting merge commit can be validated without having an extra tag. The resulting repository does not have to keep a tag reference that nobody else is interested in, which is an added bonus.
I however agree that if there were no downside having to reference and maintain an extra tag, having the data there (i.e. the real "mergetag" format) and a reference there (i.e. your alternative) would have the same level of security and assurance.
That tells us that whatever is on "mergetag" is "not fundamentally a signature", as I said already, doesn't it, though?
The description of "mergetag" in this document should not have to change, even when the mechanism used to sign underlying "tag" objects were to change in the future. For that, you can just say that it is just a bit-for-bit copy of the tag object that was pulled into the history with the merge. The way how bits from the tag object are recorded there needs to be described. What the bits mean (e.g. it has a detached GPG signature over what appeneded in what way) does not need to be (and I think should not be) repeated in the description of "mergetag".
Re: [PATCH 1/2] Documentation/technical: signature formats
In reply to Junio C HamanoW dniu 2014-10-22 21:02, Junio C Hamano pisze:
Quoted 7 lines
A mergetag is not fundamentally a "signature" in the above sense, though. It is just a dump of the object content in a regular object header field (hence indented by one SP), and its contents having PGP SIGNATURE is merely a natural consequence of the object recorded being a signed tag. So the description of it in the same place as description for signed tags and signed commits feels a little bit out of place, but I do not think of a better place to describe it.
Does this mean that you can merge annotated (but not signed) tag, and have it (as description of merged branch) in 'mergetag' header?
Signature · 1 line
Jakub Narębski
Re: [PATCH 1/2] Documentation/technical: signature formats
Jakub Narębski schrieb am 25.10.2014 um 10:30:
Quoted 10 lines
W dniu 2014-10-22 21:02, Junio C Hamano pisze:
Quoted 7 lines
A mergetag is not fundamentally a "signature" in the above sense, though. It is just a dump of the object content in a regular object header field (hence indented by one SP), and its contents having PGP SIGNATURE is merely a natural consequence of the object recorded being a signed tag. So the description of it in the same place as description for signed tags and signed commits feels a little bit out of place, but I do not think of a better place to describe it.
Quoted 2 lines
Does this mean that you can merge annotated (but not signed) tag, and have it (as description of merged branch) in 'mergetag' header?
We don't do that (so far).
In principle we could do that, of course. (But I really wish mergetag would point to the tag object rather than embed it.)
But the point of the merge tag is to "bake into the commit object" some verifiable information about the source of the merge, or rather about some of its parents.
Just adding some non-verifiable, "come-and-go" information seems to be more suited for notes.
Michael
PATCH 2/2 Documentation/technical: document push certificate format
In reply to Michael J Gruber--- Documentation/technical/signature-format.txt | 35 ++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)
Documentation/technical/signature-format.txt +35 -0
@@ -124,3 +124,38 @@ tagmess Conflicts: ... ---- + +== Push certificate + +- created by: `git push --signed` +- payload: a push certificate header followed by the push transcript + (see pack-protocol.txt) +- embedding: append the signature to the push transcript +- example: push of commit `21723` updating `master` on `localhost` + from `45cfe` + +---- +certificate version 0.1 +pusher Michael J Gruber <[email protected]> 1413979846 +0200 +pushee localhost:/tmp/t/a +nonce 1413979846-48813c0bc9d3b598d71d + +45cfec8735b7842a32dcc092a14850aa6220ef33 217230e5793407fc7c099117011ed13143fece63 refs/heads/master +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1 + +iQIcBAABCgAGBQJUR57GAAoJELR76rQkz552EWMP/3yHaFYuG3T/FcshgXQubsml +t4TvkegjQFtVK31oedqaAQGJYusXX2/yUFviXpRq611Aj7rooBnpZYZKT5lUm/ol +m9KjDvFpOiY7rA/y6BBetSX6s6uhmO4WcgJ4hSsMZ4z+001y2zawxWm0cedurIcO +hpKbAmQ/EiMmQiA4D9vKmLJUXpzF63NzMElZfWzHLa0IU1ZN6EvH1l+N7ulBNsuv +lTh3UxjabJr4vpu6kwMquCGqRB60+rdG7itiHwRQynnmDhvXoQxtU9gtLymXKJIS +SGQ5v3B5hsGA2LkCCkvNj+QRLH9LF8iAZqezqGA5U/Cg7xckOPlMwFllTv8goDBW +IB7Mk5lpQqaUCZf33uIppiEtHipLpGI90NLCm+JvzrNnnseSS6jARVRMx6cWp+dB +9QTCq80mRI/zzcvDyPhNvj0tP3mUTFmR4+KRh+4zRq9iOGp5KpJrpFjndCQELwAW +402hXEEjB4Kq7KSU4jEoaYGrJR9KJmPmgWHvz2GaJZ5eCJIXuoLGZo3TtxXRHB9p +EqWp3iZOZotxZmUVHgohFhqxZgcAefdfzZUqQ8jY3hHvu5Zwd2muToc8Nh/vIHoB +us0NHUiI8TOccAHd8AIrqgoXj2gChr3cQxWNcfBfx+ALT8sEtNrVkkrovmRiMEa4 +MxEdQTwhooEE8PWD5Yj5 +=6MAR +-----END PGP SIGNATURE----- +----
Signature · 1 line
2.1.2.756.gfa53a0a