Re: git-tag bug? confusing git fast-export with double tag objects
- From
Andreas Ericsson <ae@op5.se>
- Date
- May 16, 2009, 07:14 UTC
- Message-ID
- <4A0E67E9.3020208@op5.se>
- In-Reply-To
- <7v3ab6uuw4.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
Show 24 quoted lines
> Andreas Ericsson <ae@op5.se> writes:
>
>> Is it? Does it really make sense to have a tag named "foo" point to a tag object
>> that in turn points to a tag object without a tag ref? I mean, if you're signing
>> a tag, it makes sense to want to keep the original tag around so people can
>> reference it. If you want to *replace* a tag, it doesn't make sense to create
>> this chain which, iiuc, goes something like this:
>>
>> tag ref -> tag object -> tag object without ref -> something
>>
>> Honestly, I can see how this turned out to be confusing, as you end up with a
>> tag object without a tag, but a new tag in its place. Not to mention that the
>> new tag won't be push-able without --force in case the old tag was pushed earlier.
>
> Suppose the gpg key used to sign v1.6.3 somehow gets compromised, and I
> come up with a new gpg key. I could reassure people that the commit the
> old v1.6.3 tagged is genuine if I re-tag with the new key like this:
>
> git tag -f v1.6.3 v1.6.3^{commit}
>
> But what should I do if I would want to reassure people that both the old
> v1.6.3 was tagged by _me_ (with the old key that later was compromised)
> and that the commit that old tag tags is genuine?
> Add a tag with a new name, pointing to the original tag. Try doing what Matthias did and then run "git show $tagname". It won't show the original tag at all, so people have to resort to low-level commands in order to see it, but it will still exist as an object.
The main point though is that re-creating a ref with different content adds major headaches when distributing it. People who have the old tag and fetches from a new repo won't get the new tag stored in a ref. If the object is transferred, it will be garbage-collected.
So let's examine the scenario you described, with your gpg key being compromised.
You re-create all your tag refs with same-name tags that point to the old tags. Joe Dev fetches from you, but your tags do not get stored as refs. Joe Dev publishes a repo somewhere with a bunch of topic-branches and requests you merge from those repositories. You fetch from Joe.
Now we have two opposite problems. If tags aren't updated when Joe Dev fetches from you, his refs will not match yours when you fetch from him, and anyone cloning from him even after the re-sign will never get the new tags at all. If tag refs *do* get updated when fetching from a repo when we already have another tag ref with the same name, you fetching from Joe Dev could undo all your re-created tags and make the new tag-objects garbage-collectable. This assumes Joe Dev published his repo before fetching your new tags though.
Perhaps I'm missing something. It's 9AM here and I woke up ten minutes ago, but it seems to me that what will happen and what should happen is not entirely clear when one creates tag refs that already exist and are published.
-- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Register now for Nordic Meet on Nagios, June 3-4 in Stockholm http://nordicmeetonnagios.op5.org/ Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace.