[Solved] gpg --verify ... WARNING ?
Hi all,
Slackbuilds.org has a great reputation among slackware users. I don't understand gpg very well, so please explain why I get this on all their packages: Does this just mean that there is no central authority that has verified the identity of slackbuilds-devel@slackbuilds.org? And, when I verify a package with the asc (key) file, what am I actually accomplishing? ie, am I only verifying that no one broke into their server and replaced the file with a hacked duplicate? If so, how reliable is this? If someone breaks into the system, can't they register their own key with the same email address at any keyserver and then also upload phony keys (asc files) as well? Code:
gpg: Signature made Tue 02 Oct 2012 12:29:25 PM EDT using DSA key ID 9C7BA3B6 |
Yes, there is no central authority and the warning is just reminding you that you have no way of knowing whether the public-key you're using is authentic. Keys are often signed by other people's keys, but if you don't have those keys either then that isn't much of an aid.
Checking the Key ID and fingerprint is an important step when dealing with a new key for the first time. It's not absolute proof that you have an authentic key, but its a good first step. Your confidence in the key should grow as you continue to use it as any fake would soon show up when you try to verify new files/signatures that you download. For what it's worth (from a stranger, posting under a pseudonym on a web forum), the Key ID and fingerprint match those I have. Take from that what you will. ;) |
GPG uses a "web of trust" system, not a central authority.
I found this page with a bit of Googling: http://www.spywarewarrior.com/uiuc/g...-com-4.htm#2-6 Here's a few comments from that. First of all, GPG has taken the key-id 9C7BA3B6 and confirms that it is indeed registered to the Slackbuilds team on well-known public key servers. Then, it says that there's no way to confirm that the person who used that key to encrypt the material really was the Slackbuilds team. Theoretically, someone else could possess that same private key. The way to build trust in a key is to sign it, and to have other people sign it. Quote:
The web-of-trust model is a flexible solution to the matter of key validation ... quite a bit stronger, I feel, than any system (like SSL) which ultimately boils down to: "Trust me because I told you I'm 'Trustworthy, Inc.' " |
Thanks for the help.
So... theoretically, "I" should _not_ sign this key, right? Because "I" don't know slackbuilds personally, and can't verify anything about their identity. |
If you sign the key, your system will accept your signature and quibble no more ("yes, sir"). But the situation you describe still seems od. Slackbuild folks ought to be (already...) using a web-of-trust in association with their builds, and I frankly am puzzled (but also, ignorant) as to "well, why isn't it already trusted?"
It might be worth an e-mail or three. Write to 'em. Check in other forums. I really don't know "non-technically speaking, 'why.'" |
Quote:
|
You can always use a "local" signature, which is a signature that is not exported. It does not solve the problem of trust, but when dealing with non critical stuff which you bet is 95% secure, it removes the warning without giving the key a 100% credibility (thus poisoning the web of trust for others).
It seems to me these kind of keys would be well placed in a key-server. Just a wild idea. |
The slackbuilds-devel key is on key servers and the slackbuilds.org webiste. It is also signed by a number of well known names in slackware circles, including both Eric and Robby (who's keys are available both on the key servers and their own personal websites). This ought to be more than enough to provide a reasonable amount of confidence in it.
|
All times are GMT -5. The time now is 12:48 PM. |