Page 97
if an acquaintance of yours creates a public key, you can certify it by attaching your digital signature to it. Then anyone who knows and trusts you can also trust your acquaintance's public key.
In this case, the key came directly from a mass-produced Red Hat Linux CD-ROM. If someone were trying to masquerade as Red Hat Software, Inc., then he'd have certainly gone through a lot of trouble to do so. In this case, the lack of a certified public key is not a major problem, given the fact that the CD-ROM came directly from the Red Hat Software offices.
| NOTE |
Red Hat Software's public key is also available from its Web site at http://www.redhat.com/redhat/contact.html. The RPM sources also contain the key and are available from their FTP site at ftp://ftp.redhat.com/pub/redhat/ code/rpm. |
As mentioned earlier, not every package you'll run across is going to be signed. If this is the case, here's what you'll see from RPM:
# rpm -K bother-3.5-1.i386.rpm bother-3.5-1.i386.rpm: size md5 OK #
Note the lack of a pgp message. The size and md5 messages indicate that the package still has size and checksum information that verified properly. In fact, all recently produced package files will have these verification measures built in automatically.
If you happen to run across an older unsigned package, you'll know it right away:
# rpm -K apmd-2.4-1.i386.rpm apmd-2.4-1.i386.rpm: No signature available #
Older package files had only a PGP-based signature; if that were missing, there would be nothing left to verify.
If you happen to forget to add the correct public key to RPM's keyring, you'll see the following response:
# rpm -K rpm-2.3-1.i386.rpm rpm-2.3-1.i386.rpm: size (PGP) md5 OK (MISSING KEYS) #
Page 98
Here the PGP in parentheses indicates that there's a problem with the signature, and the message at the end of the line (MISSING KEYS) shows what the problem is. Basically, RPM asked PGP to verify the package against a key that PGP didn't have, and PGP complained.
Eventually it's going to happen: You go to verify a package, and it fails. We'll look at an example of a package that fails verification a bit later. Before we do that, let's make a package that won't verify in order to demonstrate how sensitive RPM's verification is.
First, we made a copy of a signed package, rpm-2.3-1.i386.rpm. We called the copy rpm-2.3-1.i386-bogus.rpm. Next, using Emacs (in hexl-mode, for all you Emacs buffs), we changed the first letter of the name of the system that built the original package. The file rpm-2.3-1.i386-bogus.rpm is now truly bogus: It has been changed from the original file.
Although the change was a small one, it still showed up when the package file was queried. Here's a listing from the original package:
# rpm -qip rpm-2.3-1.i386.rpm Name : rpm Distribution: Red Hat Linux Vanderbilt Version : 2.3 Vendor: Red Hat Software Release : 1 Build Date: Tue Dec 24 09:07:59 1996 Install date: (none) Build Host: porky.redhat.com Group : Utilities/System Source RPM: rpm-2.3-1.src.rpm Size : 631157 Summary : Red Hat Package Manager Description : RPM is a powerful package manager, which can be used to build, install, query, verify, update, and uninstall individual software packages. A package consists of an archive of files, and package information, including name, version, and description. #
And here's the same listing from the bogus package file:
# rpm -qip rpm-2.3-1.i386-bogus.rpm Name : rpm Distribution: Red Hat Linux Vanderbilt Version : 2.3 Vendor: Red Hat Software Release : 1 Build Date: Tue Dec 24 09:07:59 1996 Install date: (none) Build Host: qorky.redhat.com Group : Utilities/System Source RPM: rpm-2.3-1.src.rpm Size : 631157 Summary : Red Hat Package Manager Description : RPM is a powerful package manager, which can be used to build, install, query, verify, update, and uninstall individual software packages. A package consists of an archive of files, and package information, including name, version, and description. #
Page 99
Notice that the build hostname changed from porky.redhat.com to qorky.redhat.com. Using the cmp utility to compare the two files, we find that the difference occurs at byte 1201, which changed from p (octal 160), to q (octal 161):
# cmp -cl rpm-2.3-1.i386.rpm rpm-2.3-1.i386-bogus.rpm 1201 160 p 161 q #
People versed in octal numbers will note that only one bit has been changed in the entire file. That's the smallest possible change you can make! Let's see how our bogus friend fares:
# rpm -K rpm-2.3-1.i386-bogus.rpm rpm-2.3-1.i386-bogus.rpm: size PGP MD5 NOT OK #
Given that the command's output ends with NOT OK in big capital letters, it's obvious there's a problem. Since the word size was printed in lowercase, the bogus package's size was okay, which makes sense: We only changed the value of one bit, without adding or subtracting anything else.
However, the PGP signature, printed in uppercase, didn't verify. This makes sense, too. The package that was signed by Red Hat Software has been changed. The fact that the package's MD5 checksum also failed to verify provides further evidence that the bogus package is just that: bogus.
Perhaps you want to be able to verify packages but, for one reason or another, you cannot use PGP. Maybe you don't have a trustworthy source of the necessary public keys, or maybe it's illegal to possess encryption (like PGP) software in your country. Is it still possible to verify packages?
Certainly. In fact, we've already done it, in section 7.3.3. You lose the ability to verify the package's origins, as well as some level of confidence in the package's integrity, but the size and MD5 checksums still give some measure of assurance as to the package's state.
Of course, when PGP can't be used, the output from a verification always looks like something's wrong:
# rpm -K rpm-2.3-1.i386.rpm rpm-2.3-1.i386.rpm: size (PGP) md5 OK (MISSING KEYS) #
The --nopgp option directs RPM to ignore PGP entirely. If we use the --nopgp option on the preceding example, we find that things look a whole lot better:
# rpm -K --nopgp rpm-2.3-1.i386.rpm rpm-2.3-1.i386.rpm: size md5 OK #