Archive:Legacy/Security

GPG Keys

Like the previous fedora.us development, all Fedora Legacy developers are required to use GPG in a proper manner in all communications of substance. This allows messages and packages to be verifiable back to specific individuals. Most importantly this enables building the corpus of historical evidence necessary for anyone to read, verify GPG signatures, and decide based upon the contributor's good advice if they are to be trusted or not. This is part of the "web of trust" concept.

It is a good security practice to validate public keys that you receive and to only trust validated keys. Public key validation, verification, and trust models are complicated subjects. For further details please consult the GPG documentation or our GnuPG HOWTO page .

The Fedora Legacy Project key

All packages released by the Fedora Legacy Project will include the Fedora Legacy GPG key, available at:

• http://www.fedoralegacy.org/FEDORA-LEGACY-GPG-KEY
• Public keyservers such as pgp.mit.edu

The key fingerprint is as follows:

pub 1024D/731002FA 2004-01-19 Fedora Legacy (http://www.fedoralegacy.org) Key fingerprint = D66D 121F 9784 5E7B 2757 8C46 108C 4512 7310 02FA sub 2048g/D12E351D 2004-01-19

To Import the GPG key

You should import this key so that rpm will be able to verify the key when you check RPMS in the future. This can be done by one of the following commands depending on your OS version:

Red Hat 7.x:
gpg --import <keyfile>

Red Hat 8.0 and later:
rpm --import <keyfile>

For example, for Red Hat Linux 9, you can use: rpm --import http://www.fedoralegacy.org/FEDORA-LEGACY-GPG-KEY to import the key from the Fedora Legacy web site.

Note: The GPG key on the Fedora Legacy web site is alone without any other signatures. This is what we use to sign packages as there is a bug in RPM, such that when you import a key which has additional signatures in it RPM can store the key under the wrong keyid and mess up verifications. See http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=90952 for details on the bug. The key on the key-server may gather signatures from time to time, but the key on our web site will not reflect this.

Note: A side effect of the above bug is that you may see notices like the following when you try to verify packages:

gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner.

This warning can be ignored as it is simply due to our signing key not having any additional signatures so as to make it work reliably in RPM.

Verifying RPM Packages

You can verify a RPM by checking its internal checks, its GPG signature and by checking its MD5 or SHA1 checksum.

To verify an RPM package's internal checks and GPG signature, run the command:

rpm --checksig -v <filename>.rpm

The output of this command will show if RPM found any problems, and show you if the package is signed and who signed it. Compare that signature to the Fedora Legacy Project Key for packages released by the Fedora Legacy Project, or to the individual's key for packages released by individuals.

All Fedora Legacy and Red Hat RPMS are announced with either their md5 or sha1 checksum values (for example, in the e-mail message or Bugzilla posting announcing a test package or an offical release of a package). You should use these to verify that the RPM files have not been corrupted or altered. Use the following commands to generate the file's md5 or sha1 checksum, then compare it with the published checksum to make sure they match.

For md5sum checksums
md5sum <filename>.rpm

For sha1sum checksums
sha1sum <filename>.rpm

If you have downloaded a "md5sum.asc" file for an rpm, you can also verify the RPM via that file as follows (we assume the file is called md5sum.asc in this example):

md5sum -c md5sum.asc

If it is valid, the above command should generate the name of the RPM file(s) followed by a colon, a space, and the word "OK". If the file is corrupted or doesn't match, it will return an error message instead.

---

[[Category:Legacy