> -----Original Message----- > From: Junio C Hamano > Sent: Monday, August 25, 2014 13:55 > > Stefan Beller <stefanbeller@xxxxxxxxx> 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 <gitster@xxxxxxxxx> > > 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 majordomo@xxxxxxxxxxxxxxx > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html