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'. 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html