Re: [PATCH 00/18] Signed push
Stefan Beller stefanbel...@gmail.com writes: burden is not an issue, as I'll be signing the push certificate anyway when I push. A signed tag or a signed commit and signed push certificate solves two completely separate and orthogonal issues. What happens if you break into GitHub or k.org and did $ git tag maint_2014_08_22 master_2014_08_22 Ok, I personally haven't used tags a lot. I just tried to git tag -s testbreaktag v2.1.0 git show testbreaktag # However it would still read: tag v2.1.0 Tagger: Junio C Hamano gits...@pobox.com Date: Fri Aug 15 15:09:28 2014 -0700 So as I do not posess your private key I could not create signed tags even if I were to break into github/k.org The point was that after I push to 'maint', you break into the site and copy or move that tag as if I pushed to 'master'. You could argue that I could create a signed tag 'maint-2014-08-25', push it, and if you moved it to tags/master-2014-08-25 as an attacker, the refname would not match the tag line in the signed tag object. While that is true, nobody other thaan fsck checks the contents on the tag line in practice. But more importantly. I may deem a commit a sensible version for the 'master' branch of one repository but it would not be sensible for another repository's 'master' branch. Imagine a world just like the kernel development during 2.6 era used to be, where there was a separate tree 2.4 maintained with its own 'master' branch. What is appropriate for the tip of 'master' to one repository is not good for the other one, and your timestamped tag line may say for which branch the push was for but does not say for which repository. The exact problem is also shared with the desire to have a branch object expressed elsewhere; as there is no identity for a branch in a distributed world, trying to name branch as if it is a global entity without mentioning what repository will lead to tears. Besides, these tags/maint-2014-08-25 tags will be interesting only for those who are auditing and not for general public, and we do not have a good way to hide uninteresting refs until those with narrow niche interest ask yet, which is something we may want to add soon, but I do not want auditable push taken hostage to that unrelated feature. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 00/18] Signed push
-Original Message- From: Junio C Hamano Sent: Monday, August 25, 2014 13:55 Stefan Beller stefanbel...@gmail.com writes: burden is not an issue, as I'll be signing the push certificate anyway when I push. A signed tag or a signed commit and signed push certificate solves two completely separate and orthogonal issues. What happens if you break into GitHub or k.org and did $ git tag maint_2014_08_22 master_2014_08_22 Ok, I personally haven't used tags a lot. I just tried to git tag -s testbreaktag v2.1.0 git show testbreaktag # However it would still read: tag v2.1.0 Tagger: Junio C Hamano gits...@pobox.com Date: Fri Aug 15 15:09:28 2014 -0700 So as I do not posess your private key I could not create signed tags even if I were to break into github/k.org The point was that after I push to 'maint', you break into the site and copy or move that tag as if I pushed to 'master'. What is needed is not a signed push per se, but rather a need for a set of signed HEADS ... You could argue that I could create a signed tag 'maint-2014-08-25', push it, and if you moved it to tags/master-2014-08-25 as an attacker, the refname would not match the tag line in the signed tag object. While that is true, nobody other thaan fsck checks the contents on the tag line in practice. But more importantly. I may deem a commit a sensible version for the 'master' branch of one repository but it would not be sensible for another repository's 'master' branch. Imagine a world just like the kernel development during 2.6 era used to be, where there was a separate tree 2.4 maintained with its own 'master' branch. What is appropriate for the tip of 'master' to one repository is not good for the other one, ... and these signed HEADS need to be tied to a particular repository instance. AFAIK git does not have any unique identifier per repository instance to leverage. If you were to make a repository instance id you could take that and the branch name as input to a signed hash for verification later. But this leads to deeper issues about new workflow, new configuration storage mechanisms, etc. and your timestamped tag line may say for which branch the push was for but does not say for which repository. The exact problem is also shared with the desire to have a branch object expressed elsewhere; as there is no identity for a branch in a distributed world, trying to name branch as if it is a global entity without mentioning what repository will lead to tears. Besides, these tags/maint-2014-08-25 tags will be interesting only for those who are auditing and not for general public, and we do not have a good way to hide uninteresting refs until those with narrow niche interest ask yet, which is something we may want to add soon, but I do not want auditable push taken hostage to that unrelated feature. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] Signed push
On 20.08.2014 00:06, Junio C Hamano wrote: 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. What kind of additional benefit do we gain? (i.e. why?) The described problem, the lacking auditability of what's pushed at which time, could be worked around like this: Whenever you do a push, you just tag the latest commit in that branch. So there would be tags like: master_2014_08_21 master_2014_08_22 ... maint_2014_08_13 maint_2014_08_21 and so on. Whenever there is no tag at the tip of the branch, we'd know there is something wrong. My guess would be usability as tagging so many branches is cumbersome for a maintainer? Looking at my made-up workaround again: That would produce lots of tags. So I could imagine there would also be lots of push certs. The number of push certs would roughly scale linear to time passed. May this result in slowness over time? Does this patch series mean, we'd get another object type (additional to blobs, commits, tags, trees)? I did not read the code yet, it's just first thoughts, so this weigh this input lightly. Stefan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] Signed push
Stefan Beller stefanbel...@gmail.com writes: So there would be tags like: master_2014_08_21 master_2014_08_22 ... maint_2014_08_13 maint_2014_08_21 and so on. Whenever there is no tag at the tip of the branch, we'd know there is something wrong. Who creates that tag? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] Signed push
On 22.08.2014 22:03, Junio C Hamano wrote: Stefan Beller stefanbel...@gmail.com writes: So there would be tags like: master_2014_08_21 master_2014_08_22 ... maint_2014_08_13 maint_2014_08_21 and so on. Whenever there is no tag at the tip of the branch, we'd know there is something wrong. Who creates that tag? My guess would be usability as tagging so many branches is cumbersome for a maintainer? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] Signed push
Stefan Beller stefanbel...@gmail.com writes: On 22.08.2014 22:03, Junio C Hamano wrote: Stefan Beller stefanbel...@gmail.com writes: So there would be tags like: master_2014_08_21 master_2014_08_22 ... maint_2014_08_13 maint_2014_08_21 and so on. Whenever there is no tag at the tip of the branch, we'd know there is something wrong. Who creates that tag? My guess would be usability as tagging so many branches is cumbersome for a maintainer? Did you answer my question? Who creates these tags? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] Signed push
On 22.08.2014 22:33, Junio C Hamano wrote: Stefan Beller stefanbel...@gmail.com writes: On 22.08.2014 22:03, Junio C Hamano wrote: Stefan Beller stefanbel...@gmail.com writes: So there would be tags like: master_2014_08_21 master_2014_08_22 ... maint_2014_08_13 maint_2014_08_21 and so on. Whenever there is no tag at the tip of the branch, we'd know there is something wrong. Who creates that tag? My guess would be usability as tagging so many branches is cumbersome for a maintainer? Did you answer my question? Who creates these tags? It would be up to the one who pushes, the user, or in our case you! This way of working would require the informal notion of 'always tag the last commit before pushing.' As I wrote in the first email, I made up this workaround and wanted to see, what's so bad about that workaround and how to overcome the problems. And all I could find was a burden on the maintainer/user. Sorry, Stefan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] Signed push
Stefan Beller stefanbel...@gmail.com writes: On 22.08.2014 22:33, Junio C Hamano wrote: Stefan Beller stefanbel...@gmail.com writes: On 22.08.2014 22:03, Junio C Hamano wrote: Stefan Beller stefanbel...@gmail.com writes: So there would be tags like: master_2014_08_21 master_2014_08_22 ... maint_2014_08_13 maint_2014_08_21 and so on. Whenever there is no tag at the tip of the branch, we'd know there is something wrong. Who creates that tag? My guess would be usability as tagging so many branches is cumbersome for a maintainer? Did you answer my question? Who creates these tags? It would be up to the one who pushes, the user, or in our case you! ... As I wrote in the first email, I made up this workaround and wanted to see, what's so bad about that workaround and how to overcome the problems. And all I could find was a burden on the maintainer/user. burden is not an issue, as I'll be signing the push certificate anyway when I push. A signed tag or a signed commit and signed push certificate solves two completely separate and orthogonal issues. What happens if you break into GitHub or k.org and did $ git tag maint_2014_08_22 master_2014_08_22 to create an extra tag out of the tag signed by me? If you want, you could also remove the original while at it. The goal is to let us validate without having to trust the hosting site, its management and its software, which is what creates the tag there, controls where the tag sits in refs/ hierarchy and how it is shown to the outside world. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] Signed push
On 23.08.2014 00:32, Junio C Hamano wrote: Stefan Beller stefanbel...@gmail.com writes: On 22.08.2014 22:33, Junio C Hamano wrote: Stefan Beller stefanbel...@gmail.com writes: On 22.08.2014 22:03, Junio C Hamano wrote: Stefan Beller stefanbel...@gmail.com writes: So there would be tags like: master_2014_08_21 master_2014_08_22 ... maint_2014_08_13 maint_2014_08_21 and so on. Whenever there is no tag at the tip of the branch, we'd know there is something wrong. Who creates that tag? My guess would be usability as tagging so many branches is cumbersome for a maintainer? Did you answer my question? Who creates these tags? It would be up to the one who pushes, the user, or in our case you! ... As I wrote in the first email, I made up this workaround and wanted to see, what's so bad about that workaround and how to overcome the problems. And all I could find was a burden on the maintainer/user. burden is not an issue, as I'll be signing the push certificate anyway when I push. A signed tag or a signed commit and signed push certificate solves two completely separate and orthogonal issues. What happens if you break into GitHub or k.org and did $ git tag maint_2014_08_22 master_2014_08_22 Ok, I personally haven't used tags a lot. I just tried to git tag -s testbreaktag v2.1.0 git show testbreaktag # However it would still read: tag v2.1.0 Tagger: Junio C Hamano gits...@pobox.com Date: Fri Aug 15 15:09:28 2014 -0700 So as I do not posess your private key I could not create signed tags even if I were to break into github/k.org to create an extra tag out of the tag signed by me? If you want, you could also remove the original while at it. Considering I'm in the hosting server, could I delete the push cert as well? Now that I deleted the push certificate, I could pretend Junio just forgot to sign the push cert today and we're back at the tag solution? Ah wait! the subsequent push certs would not match, I'd need to delete them as well. The goal is to let us validate without having to trust the hosting site, its management and its software, which is what creates the tag there, controls where the tag sits in refs/ hierarchy and how it is shown to the outside world. Ok, I got the goal. :) Thanks for your patience, Stefan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] Signed push
No code == no substance might be a stretch, but definitely fair enough. I thought the idea was clear enough, but I can flesh it out if desired. The particular advantage I saw in it is that it would reuse the existing object infrastructure, and extend to branches the first-class treatment that [signed] tags already get. I.e., generality. Other benefits include the ability to fetch and view a remote branch's object and its history (which would represent branch history in detail and with metadata that would otherwise not be available). I'm not interested in pushing something different when you already have code that would achieve much of what I'd wanted. At this point my interest is in seeing if the architecture would be purer (in some sense) by reusing existing infrastructure. Nico -- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/18] Signed push
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. The most interesting part starts at 15/18; everything that precedes that patch are preparatory clean-ups. [PATCH 15/18] the beginning of the signed push This step presents the basic idea. If you remember the underlying git push protocol exchange, it goes like this: - The server advertises the existing refs and where they point at, and the capabilities the server supports; - The git push client sends update commands (one or more old-sha1 new-sha1 refname) followed by the pack data; - The server unpacks and updates the refname to point at new-sha1. We introduce push-cert capability, and allow the client to sign the update commands it will send to the server and send this signature using the new push-cert command. This certificate is exported to the pre/post-receive hooks of the server, so that the pre-receive hook can GPG validate (and possibly reject a bad push); post-receive hook can log the certificate. [PATCH 16/18] receive-pack: GPG-validate push certificates This step builds a native GPG validation into the server to help the pre-receive hook. The signature is verified against the GPG keychain the server uses (it is likely that you would want to set and export GNUPGHOME when starting your server), and verification result is given to the pre/post-receive hook. [PATCH 17/18] send-pack: send feature request on push-cert packet [PATCH 18/18] signed push: final protocol update With the protocol introduced in 15/18, the update commands and the push certificate record the same information twice; the protocol was kept inefficient to make it easier to review the changes. These two steps updates the protocol to the final version, which does not to send the update commands when a push certificate is in use. If the server's GPG keychain and pre-receive hook are properly set up, a git push --signed over an unauthenticated and unencrypted communication channel (aka git daemon) can be made as secure as, and even more secure than, the authenticated git push ssh://. With the signed push certificate, together with the connectivity check done when the server accepts the packed data, we are assured that the trusted user vouches for the history leading to the proposed tips of refs (aka new-sha1s), and a man-in-the-middle would not be able to make the server accept an update altered in transit. Junio C Hamano (18): receive-pack: do not overallocate command structure receive-pack: parse feature request a bit earlier receive-pack: do not reuse old_sha1[] to 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: final protocol update Documentation/git-push.txt| 9 +- Documentation/git-receive-pack.txt| 30 +++- Documentation/technical/pack-protocol.txt | 24 ++- Documentation/technical/protocol-capabilities.txt | 12 +- builtin/push.c| 1 + builtin/receive-pack.c| 161 +++--- commit.c | 36 - gpg-interface.c | 57 +++ gpg-interface.h
Re: [PATCH 00/18] Signed push
On Wed, Aug 20, 2014 at 5:06 AM, Junio C Hamano gits...@pobox.com wrote: 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. I only had a quick read of a few important patches and may miss something. But all this audit recording is left to the hook, right? I suppose git-notes could be used to store the push cert. blob, or the server could make a signed tag to record this info in the ref.. or do you intend any other way to record these blobs? -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] Signed push
I don't think anybody can come up with a good auditing and recording scheme without sufficient experience. Because I want to avoid whatever random scheme we happen to implement first in git-core, even if it is way suboptimal, ends up as the de-facto standard, I deliberately stayed away from adding one of my own in this initial series, whose purpose is to lay a groundwork for server operators can build on. For the same reason, I tried to avoid anything that defines and forces a particular policy (e.g. does a server that accepts push certificate accept an unsigned push to some of its refs? Is it OK if the GPG key is slightly stale? etc.). git notes may or may not be a good vehicle to store them. This series deliberately refrains from making that judgement. I'd rather leave these operational issues to folks who work on systems like Gitolite and Gerrit. On Tue, Aug 19, 2014 at 4:07 PM, Duy Nguyen pclo...@gmail.com wrote: On Wed, Aug 20, 2014 at 5:06 AM, Junio C Hamano gits...@pobox.com wrote: 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. I only had a quick read of a few important patches and may miss something. But all this audit recording is left to the hook, right? I suppose git-notes could be used to store the push cert. blob, or the server could make a signed tag to record this info in the ref.. or do you intend any other way to record these blobs? -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] Signed push
On Tue, Aug 19, 2014 at 03:06:09PM -0700, Junio C Hamano wrote: 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. [...] 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. Sounds a lot like the branch object concept I suggest earlier, where each push would also push a commit to a branch object describing the updates to the branch, including signing of the updates to the branch (hey, it's just a signed commit), groups of commits pushed together / to be backed out together, rebase history, ... (What about pushing orphaned commits?) Code-wise, would that be more or less generic? Nico -- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] Signed push
On Tue, Aug 19, 2014 at 3:06 PM, Junio C Hamano gits...@pobox.com wrote: If the server's GPG keychain and pre-receive hook are properly set up, a git push --signed over an unauthenticated and unencrypted communication channel (aka git daemon) can be made as secure as, and even more secure than, the authenticated git push ssh://. With the signed push certificate, together with the connectivity check done when the server accepts the packed data, we are assured that the trusted user vouches for the history leading to the proposed tips of refs (aka new-sha1s), and a man-in-the-middle would not be able to make the server accept an update altered in transit. The above was written long after the series was done, but rethinking about it within that frame of mind helped me find one nit in the push certificate design. We would need a PKT-LINE(pushed-to SP URL LF) in the header part to prevent the certificate and the same set of refs from getting replayed. Otherwise, a different repository that happens to have the same set of refs with same set of old-sha1 values can be made to accept a push that the signer never intended to make to it by replaying an earlier push to a different site the signer did make. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] Signed push
Sorry, but I cannot answer, as the only thing that I recall when I hear branch object was that I heard the phrase used but without much substance. I do not think I saw a clear explanation on what it is, how it is represented, how it is presented to the end user, how it is propagated across repositories (if it is to be propagated), how it is stored (if it is to be stored), how it is to be used, etc. and such crucial details necessary to judge the merit of thinking about introducing one. Perhaps it was explained in the old thread, but I don't recall, so I cannot judge how useful it would be to solve the problem the push certificate is trying to solve. On Tue, Aug 19, 2014 at 6:19 PM, Nico Williams n...@cryptonector.com wrote: On Tue, Aug 19, 2014 at 03:06:09PM -0700, Junio C Hamano wrote: 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. [...] 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. Sounds a lot like the branch object concept I suggest earlier, where each push would also push a commit to a branch object describing the updates to the branch, including signing of the updates to the branch (hey, it's just a signed commit), groups of commits pushed together / to be backed out together, rebase history, ... (What about pushing orphaned commits?) Code-wise, would that be more or less generic? Nico -- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] Signed push
On Tue, Aug 19, 2014 at 7:54 PM, Junio C Hamano gits...@pobox.com wrote: Sorry, but I cannot answer, as the only thing that I recall when I hear branch object was that I heard the phrase used but without much substance. Just to avoid unnecessary misunderstanding, by the above, especially the without much substance part, I do not mean that those without code have no say in the way the project improves its product. It is true that this project does not operate in such a way that visionaries throw ideas for coding minions to implement. A person with an itch and idea on how to scratch that itch is expected to lead the design and code, possibly with help from others. But in order to ask others evaluate and join force to help with the design and make it real with code, you need to present your idea to sufficient level of detail to be actionable. By actionable, consider the level of detail in which the proposed log message (not code or documentation update) of PATCH 15/18. Even though the message alone does not give any working code, or it does not even spell out the byte-level detail of how the protocol messages look like, people should be able to read enough details such as what kind of information a push certificate is to contain, when a certificate is created, how it is transferred, when and by whom it is received, how it will be used by the receiver, how a server operator can tweak his or her system to make use of the information, and how the newly added system component would fit into the existing system. In other words, the description should be sufficient to assess both how useful the end result would be, how much new work needs to be done to get there, and how well the resulting system as a whole would fit together well. I went back to the old thread to re-read the mention of branch object, but I did not get an impression that the idea was presented to the actionable level of detail; at least not yet. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
