RPM is the standard for installing and managing software on Red Hat and SUSE. Meta package handlers such as Yum and Zypper make it easy to install packages. But, RPM can be dangerous because during installation scripts are executed with root permissions automatically. So, make sure you trust the RPM package. If you create RPM packages yourself, it's a good idea to sign them using a Gnu Privacy Guard (GnuPG or GPG) key.
In GPG, public/private-key pairs are used to ensure confidentiality. You can use them to encrypt files or as a digital signature that ensures that an email really comes from the listed sender. They can also be used to sign PRM packages.
When signing RPM packages, the creator of the RPM package needs to go through a signing procedure. This signature can be checked against the GPG key, which should be publicly available and can be imported by the person installing the package. If the signature matches this publicly available GPG key, the person who downloads the package has a guarantee that the package is signed by the GPG key that is joined with the package. This procedure is convenient, but it doesn't offer 100% guarantee. If the source where the package is offered gets compromised, both the RPM package and key may be falsified. Signing packages does increase the package security because the hacker needs to perform two hacks before the forged package can be offered.
If you want to offer signed RPM packages, you need to apply the following procedure:
1. Create a gpg key-pair. This generates a generic key pair that you can use for multiple purposes. To create it, use the gpg --gen-key command and specify the properties of the key. Before the key can be generated, you need to generate some random data, so make sure to generate disk activity to speed up the process of key generation. Below is the result of the gpg --gen-key command:
gpg: key 455F7CBF marked as ultimately trusted
public and secret key created and signed.
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u
pub 1024R/455F7CBF 2011-04-07
Key fingerprint = 4C78 4A47 1B84 E769 4ADD C43D 31DA C76F 455F 7CBF
uid Sander van Vugt <email@example.com>
sub 1024R/68D74CDD 2011-04-07
2. Now that you have the key pair, you need the key ID. Using the key ID, you need to create a key file. The key ID is what you see in the output of the gpg command in the pub line. In the example above, the key ID is 455F7CBF. The following command will create a file in the home directory of the current use that you can use to sign the key:
gpg -a -o ~/RPM-GPG-KEY-test --export 455F7CBF
3. Next, in the home directory of that same user, you have to create a .rpmmacros file that has the following content:
4. At this point, you can (re)sign the package. The command below is used to sign an RPM package that has just been created and is available in the RPM build directory:
rpm --resign ~/rpmbuild/RPMS/x86_64/test-1.0-1.fc14.x86_64.rpm
5. At this point, you have a signed package and a key for the user to verify integrity of the package to use. You need to publish the key with the signed package. But first you need to test it. The following two commands conduct a local test; the first commands imports the GPG package, and the next command uses yum localinstall to install the package without the need to set up a repository:
rpm --import ~/RPM-GPG-KEY-test
yum localinstall ~/rpmbuild/RPMS/x86_64/test-1.0-1.fc14.x86_64.rpm
ABOUT THE AUTHOR: Sander van Vugt is an author and independent technical trainer, specializing in Linux since 1994. He is also a technical consultant for high-availability (HA) clustering and performance optimization, as well as an expert on SLED 10 administration.