From: Eric W. Biederman Date: Fri, 01 Jul 2005 23:07:19 GMT Subject: Re: Tags Message-ID: In-Reply-To: <42C5C75F.4040100@zytor.com> "H. Peter Anvin" 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