Re: [PATCH 00/18] Signed push

[Junio C Hamano <gitster@pobox.com>]

Stefan Beller <stefanbeller@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 <gitster@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.