LuKreme wrote: > On 11-Dec-2008, at 07:39, Bowie Bailey wrote: > > > > It's almost like "Just download this key file and you'll be fine. > > Don't worry about where it came from, just put it in your keyring." > > Not at all, I KNOW where the gpg.key came from, because I downloaded > it. And it came from the same server as the rules are coming. > > > The point is that at some point you have to trust the source to > > give you the correct information. (Which, in the case of an > > encryption key or key id, will look like a bunch of random numbers) > > The KeyID is coming from who knows where.
the KeyID came from the original announcement of the ruleset by the author. This is currently hosted on his blog. http://taint.org/2007/08/15/004348a.html > > > > Because sa-update is designed to provide updates in a secure > > > > way. If you want the simplest way, you can ignore these steps > > > > and face the consequences when something goes wrong. > > > > > > Oddly enough, I am able to encrypt emails, sign emails, verify > > > signed mails, login to ssh ports on remote servers and do a > > > whole host of secure things without ever having encountered > > > anything like this gpgkey. I've added the key to the keychain as > > > a trusted key, that is enough to make it secure. How is this 8 > > > digit hex code making anything any more secure? > > > > Because it specifies WHICH key in your keyring is allowed to sign > > the updates. > > So the concern is that someone who produces RULES1 for SA would hijack > RULES2's server and then create a new RULES2 set, sign it with their > RULES1 key, and wait for people to sync up with it? Because it would > require all of that, right? > > Probability seems low. If you know that the updates will only ever be signed by one key, why not specify it? It doesn't cost you anything and gives a slight increase in the security level even if it is unlikely anyone would attempt to fake an update. -- Bowie
