On Thu, 2004-11-04 at 17:25 -0500, Peter Jones wrote: > On Thu, 2004-11-04 at 15:02 -0600, Satish Balay wrote: > > On Thu, 4 Nov 2004, Peter Jones wrote: > > > > > Signing something with the Red Hat key and signing something with the > > > Rawhide key are currently _the same thing_, and no amount of telling > > > people that it's not is going to change that. > > > > (I didn't want to get sucked into this again - but couldn't > > resist.. this tread never dies). > > > > I hope you can give pointed answers to these 2 questions. > > > > 1. If 'Red Hat key' == 'Rawhide key' - why do you have both? > > I think it's horribly ill-conceived that we have both. That is, we have > both because people have fallen into this mistake. > > > 2. How does packages signed by 'at-rpms-key' fit in your grad model > > where all keys are the same - and users don't know how to distinguish > > them. > > Both models have the keys being the same. One has people refusing to > acknowledge this. > > The current model is that they're all the same. Look at our tools; look > at yum and up2date. They don't know anything about which key is which, > just which key you've said you trust (not even what you trust it for, or > how much). The only real difference, and certainly the only one in the > minds of the vast majority of our users, is that one comes in rpm's key > list by default and one does not. An RFE for yum has been to provide a list of gpg keyids that are valid per-repository. So then the gpgcheck process would be: 1. check if the sig exists 2. check if the sig is valid 3. if both are true, check to see if the keyid matches on the allowed keyid for packages from that repo. I've written the code to do the keyid return as an alternative type of check. I've just not bolted it into the config parsing in yum. I was hovering around the idea a bit b/c I'm concerned of the impact of carrying this feature along forever. This, obviously, begins setting up the infrastructure to allow a user to add their own value to specific keys. Thoughts? -sv