Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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?
gpg: Signature made Tue 02 Oct 2012 12:29:25 PM EDT using DSA key ID 9C7BA3B6
gpg: Good signature from "SlackBuilds.org Development Team <firstname.lastname@example.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: D307 6BC3 E783 EE74 7F09 B8B7 0368 EF57 9C7B A3B6
Last edited by stringchopper; 03-07-2013 at 02:48 PM.
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.
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.
When you sign and certify someone else's public key, you are making a statement about your confidence that the public key you're signing actually belongs to the person specified in the User ID for that key. By signing someone's public key, you are building the Web of Trust for the keys on your own keyring and contributing to the Web of Trust for the larger community GPG and PGP users. Until you sign someone's public key and change the trust level associated with that key, GPG will warn you that the key is untrusted whenever you use that key to verify signatures or encrypt files and messages.
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.' "
Last edited by sundialsvcs; 03-03-2013 at 10:08 PM.
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.'"
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.