Re: Tags

From: Eric W. Biederman <ebiederm@xmission.com>
Date: Jul 1, 2005, 23:07 UTC
Message-ID: <m1ll4qf7mg.fsf@ebiederm.dsl.xmission.com>
In-Reply-To: <42C5C75F.4040100@zytor.com>

"H. Peter Anvin" <hpa@zytor.com> writes:

Show 13 quoted lines

> Eric W. Biederman wrote:
>> There is a question of how bad is this.   For releases you certainly
>> need some kind of signature that people can verify and we
>> already have that but I think we can keep spoofing tags
>> down to the same level as spoofing patches.
>> Basically all this takes is to make your global namespace
>> the committer email address and you have the rule that
>> you can only tag your own commits.  Then when you merge
>> tags you never automatically add tags to your own tag namespace.
>>
>
> Doesn't work.  You can trivially generate a key with someone else's address.  It
> would require a full PKI.

I'm not saying it's provable correct. I'm simply saying it is as correct as the rest of the git repository.

If I really care what developer xyz tagged I will pull from them, or a mirror I trust. And since developer xyz doesn't pull his own global tags from other repositories that should be sufficient.

Plus if you pull from a spoofed tag somewhere further along when you merge your code the merge will fail because what you thought was a common ancestor isn't. And you will also likely get an error when you have the same tag coming from 2 different sources with different values.

So all I am really arguing is that using the committer email address is simply sufficient to prevent non-malicious conflicts between developers, and it makes it enough that to get a malicious conflict isn't completely trivial. So I think it is good enough.

But for releases and things lots of people must trust yes you want a full PKI infrastructure but I don't see a reason any of that should be inherently tied to tags.

Eric