Re: Tags

[ebiederm@xmission.com (Eric W. Biederman)]

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

> 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