Библиотека сайта rus-linux.net
|Maximum RPM: Taking the Red Hat Package Manager to the Limit|
|Prev||Chapter 7. Using RPM to Verify Package Files||Next|
Here we've added Red Hat's public key, since we're going to check some
package files produced by them. The file
RPM-PGP-KEY contains the key. At the end, PGP asks
us if we want to certify the new key. We've answered "no" since it
isn't necessary to certify keys to verify package files.
While the output might seem somewhat anti-climactic, we can now be nearly 100% certain this package:
was produced by Red Hat.
is unchanged from their original copy.
The output from this command shows that there are actually three distinct features of the package file that are checked by the -K option:
sizemessage indicates that the size of the packaged files has not changed.
pgpmessage indicates that the digital signature contained in the package file is a valid signature of the package file contents, and was produced by the organization that originally signed the package.
md5message indicates that a checksum contained in the package file and calculated when the package was built, matches a checksum calculated by RPM during verification. Because the two checksums match, it is unlikely that the package has been modified.
OK means that each of these tests
were successful. If any had failed, the name would have been printed in
parentheses. A bit later in the chapter, we'll see what happens when
there are verification problems.
With a bit of digging, we can see that each of the three tests was performed, and each passed. The reason for that dire-sounding warning is that PGP is meant to operate without a central authority managing key distribution. PGP certifies keys based on webs of trust. For example, if an acquaintance of yours creates a public key, you can certify it by attaching your digital signature to it. Then anyone that 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 CDROM. If someone was trying to masquerade as Red Hat then they 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 CDROM came directly from the Red Hat offices. 
Note the lack of a
pgp message. The
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.
Older package files had only a PGP-based signature; if that was missing, there was nothing left to verify.
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, to demonstrate how sensitive RPM's verification is.
First, we made a copy of a signed package,
rpm-2.3-1.i386.rpm, to be specific. We called
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
rpm-2.3-1.i386-bogus.rpm is now truly bogus:
it has been changed from the original file.
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):
Given that the command's output ends with
OK in big capital letters, it's obvious there's a
problem. Since the word
printed in lowercase, the bogus package's size was OK, 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. Again, this makes sense, too. The package that was signed by Red Hat 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 the section called When You Are Missing the Correct Public Key. 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.
The lines starting with
extra output produced by the -vv option. This
output is normally used by software developers in the course of adding
new features to RPM and is subject to change, but there's no law
against looking at it.
Briefly, the output shows that RPM has detected a new-style signature block, containing size, MD5 checksum, and PGP signature information. The size of the signature, the size of the package file's header and archive sections, and the expected size of those sections are all displayed.
The --rcfile option is used to specify a file
containing default settings for RPM. Normally, this option is not
needed. By default, RPM uses
/etc/rpmrc and a
.rpmrc located in your login
This option would be used if there was a need to switch between
several sets of RPM defaults. Software developers and package
builders will normally be the only people using the
--rcfile option. For more information on
rpmrc files, see Appendix B.
Red Hat Software's public key is also available from their website, 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.
Только зарегистрированные пользователи могут оценивать и комментировать статьи.