When I do this, I'm given the message "This key is not certified with a trusted signature". Is there anyway to make it trusted and better yet what's the proper way for doing so?
A "trusted signature" is a signature from a key that you trust, either because (a) you have personally verified that it belongs to the person to whom it claims to belong, or (b) because it has been signed by a key that you trust, possibly through a series of intermediate keys.
You can edit the trust level of keys by running "gpg --edit-key ", and then using the trust command. This section of the GPG manual discusses key trust, and it's worth a read: good security is hard.
Note that the warning "This key is not certified with a trusted signature" basically means, "this thing could have been signed by anybody". I can create a key that claims to be for "Internet Systems Consortium, Inc. (Signing key, 2013) ", and sign things with it, and GPG will happily confirm that yes, the things I signed were signed with my key. To avoid this problem, you would presumably download the ISC GPG key from the website and either trust it ultimately ("I believe this entity can certify itself") or sign it with your ultimately-trusted private key. Without proper management of key trust, signature verification is mostly theater.
Find out when it expires?
Running gpg -k <keyid> will show you when a given key expires. For example, I created a key that expires tomorrow, and gpg -k <keyid> gives me:
$ gpg -k 0xD4C2B757C3FAE256
pub 2048R/0xD4C2B757C3FAE256 2014-01-26 [expires: 2014-01-27]
uid [ultimate] Test User <testuser@example.com>
sub 2048R/0xE87A56CDCC670D7A 2014-01-26 [expires: 2014-01-27]
You can see that the expiration dates on subkeys are clearly marked. Note that subkeys used for signing and encryption may have different expiration dates from the primary key. You can read more about subkeys here.
In fact does GPG tells me when the key I've imported has already expired when I do a "gpg --verify"?
Yes, GPG will notify you about an expired key. Note that this does not necessarily represent a problem: the signature was valid when the document was signed.
Update the key. Do I have to delete the key and re-import when this happens?
You should have you GPG environment configured to use a keyserver, and periodically run gpg --refresh-keys. This will update any keys in your keyring with new information from the keyserver, which may include:
- new expiration dates
- additional signatures on the key
If a person or organization begins using a new key, you would just add it to your keychain -- you would not need to delete the existing key.
It's a cluster of RPM bugs. Not just one bug, or two bugs. A nest of the critters. RPM fails (failed?) to validate signed packages, didn't understand v4 GPG signatures but didn't notice it didn't understand them, didn't understand some key sizes and types but didn't notice it didn't understand that, and also choked on subkeys!
This lifesaving blog entry by Jacob Helwig, as pointed out by a colleague, covers the issues:
You must force GnuPG to use v3 signatures when signing on/for RHEL / CentOS 5 or 6 in your `
%__gpg_sign_cmd %{__gpg} \
gpg --force-v3-sigs --digest-algo=sha1 --batch --no-verbose --no-armor \
--passphrase-fd 3 --no-secmem-warning -u "%{_gpg_name}" \
-sbo %{__signature_filename} %{__plaintext_filename}
because RPM doesn't check the sigversion or validate the signed package after signing it, and these distros contain GPG versions that default to v4 signatures.
You must also generate a 2048 bit signing-only RSA key with no subkeys.
A couple of relevant bugs:
Best Answer
Just ran into a very simalar problem and by deleting the problem key in
/etc/apt/trusted.gpg.d/{Problem-Key}.ascI was able to solve the issue!Hope this helps!