Chapter 12

Controlling the Build with rpmbuild

Copyright (c) 2005 by Eric Foster-Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/).

In This Chapter

*	Building with the rpmbuild command

*	Building RPMs without an external spec file

*	Working with source RPMs

*	Optimizing builds

*	Signing built RPMs

The preceding chapters in this Part cover details on how to put together RPMs. This chapter rounds out the discussion by delving into more details on the rpmbuild command.

You can customize how rpmbuild creates RPMs, and you can use RPM commands to test and debug your package.

Building RPMs with the rpmbuild Command

The rpmbuild command provides a workhorse command for building RPMs in all sorts of ways. The basic syntax, as shown in Chapter 9, is:

rpmbuild -bBuildStage spec_file

The BuildStage is a letter, such as c, to prepare and compile the application, executing through the %build section, or i, to execute through the %install section. This allows you a good deal of flexibility for building the entire RPM or stopping at some point prior to a full build.

There’s more to the rpmbuild command, though. Quite a few additional options allow you to further customize the build.

Note

As mentioned in Chapter 9, previous versions of the RPM system used the rpm command with a -b, for build, option. This option is no longer supported. Use the rpmbuild command to build RPMs.

Customizing the build

You can customize the rpmbuild command with the options listed in Table 12-1.

Table 12-1 Extra build options for the rpmbuild command

Option	Usage
--buildroot directory	Override the default root directory for building with directory, generally not very useful since most packages already name a buildroot
--clean	Remove the build tree after building
--nobuild	Just test the spec file and do not run the build
--rmsource	Remove the sources after the build
--rmspec	Remove the spec file after the build
--short-circuit	With the -bc or -bi options, jump directly to the given stage and resume the build from that stage
--sign	Sign the package with a GPG signature
--target platform	Build for the given platform. May not work if you don't have the other platform build commands, such as cross compilers, set up. Can work for Intel platforms with i386, i686, and so on.

Testing the build

One of the most useful options is --nobuild, which tells the rpmbuild command to not build anything. This may seem silly, but the --nobuild option is very useful for testing whether your RPMs can be built. With the --nobuild option, the rpmbuild command parses the spec file and checks for errors, but does not run any of the build stages.

The --buildroot allows you to specify a different top-level directory for building, overriding the BuildRoot tag in the spec file. This means you can build in a separate location, which is helpful in case there are mistakes. Using a separate directory means the build won’t get mixed with anything else in the build root directory.

Debugging the build

The --short-circuit option tells the rpmbuild command to restart at a particular location in the build. Rather than working its way through all the steps up to the build stage you ask for, the --short-circuit option allows the rpmbuild command to restart just at the step you ask for.

Note

This works with the -bc and -bi options only, as well as the -tc and -ti options covered later in this chapter.

For example, if you run the rpmbuild -bc command to stop after the %build section, you can use the --short-circuit option to restart the build at the %build section. If you found a problem in the %build section and corrected it, you can quickly get going again by restarting the build at the %build section rather than extracting all the sources yet again.

This option is most useful when you are compiling a package, hit an error, and fix that error. Without the --short-circuit option, you’ll likely end up spending a lot of time recompiling the code you have already compiled.

During normal development of an RPM package, you will likely execute each build section, one at a time, stop, fix any errors and restart where you left off. You’ll go through this cycle a number of times before the RPM finally builds right.

Warning

Never distribute an RPM made with the --short-circuit option. Instead, once you have everything working, start from scratch and rebuild the RPM. This is to avoid any problems with a partially-created RPM.

Cleaning up

The --clean option tells the rpmbuild command to remove the build tree when complete. This helps ensure that the next time you run the rpmbuild command, you are starting from a known situation.

For example:

$ rpmbuild --clean /usr/src/redhat/SPECS/jikes.spec

Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.98247

+ umask 022

+ cd /usr/src/redhat/BUILD

+ rm -rf jikes-1.17

+ exit 0

You can use the --clean option alone, as shown previously, or in concert with another option such as -bi to build and install a binary RPM. In the latter case, the rpmbuild command will clean the built files after the rest of the command finishes.

Similarly, the --rmsource option tells the rpmbuild command to remove the sources after completing the command. You can call this option with another option, such as -bi for building and installing a binary RPM (and then removing the sources), or alone on the command line to remove the sources only.

For example:

rpmbuild --rmsource jikes.spec

Note

The abbreviation rm is short for remove. It comes from the Linux rm command, used for removing files.

The --rmspec option tells the rpmbuild command to remove the spec file when done with the command. As with the --rmsource option, you can use the --rmspec option in conjunction with another rpmbuild option or on its own to just remove the spec file.

For example:

rpmbuild --rmspec jikes.spec

Warning

The file you are removing with this command is the spec file you are passing to the command. Be careful, because you cannot undo this operation and you have now lost your spec file, except inside your source package.

Building for other platforms

The --target option tells the rpmbuild command to build a package for another platform. You need to pass the name of the platform. For example:

rpmbuild -bi --target i486-redhat-linux

The basic format is:

cpu-vendor-os

For example, i686-redhat-linux specifies a 686 CPU with Red Hat Linux. Other CPUs include ppc for PowerPC and sparc for Sun SPARC.

Cross Reference

The --target option sets the target architecture at build time. Chapter 4 covers how you can use the --ignoreos and --ignorearch options when installing RPMs to ignore the operating system and architecture that is flagged within the RPM. Of course, this works only if you are installing on a compatible architecture.

On the surface level, the --target option overrides some of the macros in the spec file, %_target, %_target_arch, and %_target_os. This flags the RPM for the new target platform.

Under the covers, setting the architecture macros is not enough. You really cannot create a PowerPC executable, for example, on an Intel-architecture machine, unless you have a PowerPC cross compiler, a compiler that can make PowerPC executables.

Warning

Set the target with care. Make sure you can really build executable programs for that architecture.

If you try to compile a system that uses the GNU configure system to configure the build, your target will likely be ignored. For example, if you try to build the aforementioned jikes package with a target of ppc-ibm-aix, to specify IBM’s UNIX, called AIX, on a PowerPC architecture, you will see the target ignored as the configure system detects that it's running on Linux on an i686 architecture.

For example:

$ rpmbuild -bc --target ppc-ibm-aix /usr/src/redhat/SPECS/jikes.spec

Building target platforms: ppc-ibm-aix

Building for target ppc-ibm-aix

Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.94955

+ umask 022

+ cd /usr/src/redhat/BUILD

+ LANG=C

+ export LANG

+ cd /usr/src/redhat/BUILD

+ rm -rf jikes-1.17

+ /usr/bin/gzip -dc /usr/src/redhat/SOURCES/jikes-1.17.tar.gz

+ tar -xf -

+ STATUS=0

+ '[' 0 -ne 0 ']'

+ cd jikes-1.17

++ /usr/bin/id -u

+ '[' 500 = 0 ']'

++ /usr/bin/id -u

+ '[' 500 = 0 ']'

+ /bin/chmod -Rf a+rX,g-w,o-w .

+ exit 0

Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.15710

+ umask 022

+ cd /usr/src/redhat/BUILD

+ cd jikes-1.17

+ LANG=C

+ export LANG

+ ./configure CXXFLAGS=-O3 --prefix=/tmp/jikesrpm/usr

checking for a BSD-compatible install... /usr/bin/install -c

checking whether build environment is sane... yes

checking for gawk... gawk

checking whether make sets ${MAKE}... yes

checking whether to enable maintainer-specific portions of Makefiles... no

checking build system type... i686-pc-linux-gnu

checking host system type... i686-pc-linux-gnu

checking for g++... g++

As you can see, the command starts out with the target as the platform, but the configure script soon overrides that, as shown at the end of the truncated output.

Building RPMs Without an External Spec File

Most of the options for the rpmbuild command require an RPM spec file. This file defines all the necessary parameters for the RPM to build. If you’ve downloaded an application, though, you may not have all the information needed to build a spec file. In addition, writing the spec file is the most time-consuming task when building RPMs. If you are lucky, the provider of a given application may have already created a spec file and included the spec file within the source distribution.

Options for working with tar archives

A special set of options aims toward building RPMs with spec files stored in tar archives, also called tarballs. Tarballs are files combined with the tar (tape archiver) utility and then optionally compressed, usually with the gzip command. Because this format is used so often for UNIX and Linux software, you can use a set of -t options to the rpmbuild command that mimic the -b options.

The basic syntax follows:

rpmbuild -tBuildStage compressed_tar_archive

The -t option is a lot like the -b option covered in Chapter 9, except -t tells rpmbuild to build an RPM from a compressed tar archive instead of from an RPM spec file. You still need a spec file. These commands just assume that the spec file is located within the tar archive. The extra BuildStage option is a special code that tells the rpmbuild command how far to go when building. Table 12-2 lists these options:

Table 12-2 Options for building with rpmbuild with tar archives

Option	Usage
-ta	Build all, both a binary and source RPM
-tb	Build a binary RPM
-tc	Stop after the %build section
-tp	Stop after the %prep section
-ti	Stop after the %install section
-tl	Check the listing of files for the RPM
-ts	Build a source RPM only

Note

These command-line options work with a tar archive or a compressed tar archive.

The expected archive structure

To build a package this way, the tar archive must have enough of an expected structure, such as a configure script and a Makefile with the expected make targets. The most crucial element is that the tar archive must have the package spec file.That’s because the rpmbuild command doesn’t know how to build every program in the universe. Instead, rpmbuild expects to find a spec file to tell it what to do. If you see an error like the following, then your tar archive likely is missing the spec file:

$ rpmbuild -tc vixie-cron*tar.gz

error: Name field must be present in package: (main package)

error: Version field must be present in package: (main package)

error: Release field must be present in package: (main package)

error: Summary field must be present in package: (main package)

error: Group field must be present in package: (main package)

error: License field must be present in package: (main package)

These errors show expected tags from the missing spec file.

Working with Source RPMs

Most of your work with the rpmbuild command will likely be to create binary RPMs after you have the sources for an application and a spec file. You can also get a lot of mileage out of source RPMs, whether you build them or download them.

Cross Reference

Chapter 10 covers the spec file in depth.

Because they are RPMs themselves, source RPMs act like other RPMs. For example, you can use the rpm -i command to install a source RPM. This installs the sources provided by the source RPM, not the actual application. Normally, when you install a source RPM on a Red Hat Linux system, the package gets installed into /usr/src/redhat.

Note

This directory is obviously specific to Red Hat Linux. On other Linux distributions, you'll likely see directories such as /usr/src/OpenLinux for SCO (formerly Caldera) OpenLinux.

Installing a source RPM is not exactly the same as installing a binary RPM. For example, the rpm command does not update the RPM database when you install a source RPM. In addition, listing the files in a source RPM only shows the relative paths, not the full paths.

Once installation is complete, you can use the rpmbuild command to create a binary RPM from the sources in the source RPM, using the -b command-line options introduced in Chapter 9. The next sections show more shortcuts with source RPMs.

Rebuilding binary RPMS from source RPMs

As a shortcut, you do not have to install a source RPM to create a binary RPM. Instead, you can build the binary RPM directory using the --rebuild option.

The --rebuild option tells the rpmbuild command to rebuild a binary RPM from a source RPM file. The basic syntax is:

rpmbuild --rebuild package.src.rpm

This command builds a binary RPM out of a source RPM with a minimum of fuss. For example:

$ rpmbuild --rebuild unix2dos-2.2-17.src.rpm

Installing unix2dos-2.2-17.src.rpm

Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.15828

+ umask 022

+ cd /usr/src/redhat/BUILD

+ LANG=C

+ export LANG

+ cd /usr/src/redhat/BUILD

+ rm -rf unix2dos-2.2

+ /bin/mkdir -p unix2dos-2.2

+ cd unix2dos-2.2

+ /usr/bin/gzip -dc /usr/src/redhat/S OURCES/unix2dos-2.2.src.tar.gz

+ tar -xf -

+ STATUS=0

+ '[' 0 -ne 0 ']'

++ /usr/bin/id -u

+ '[' 500 = 0 ']'

++ /usr/bin/id -u

+ '[' 500 = 0 ']'

+ /bin/chmod -Rf a+rX,g-w,o-w .

+ echo 'Patch #0 (unix2dos-mkstemp.patch):'

Patch #0 (unix2dos-mkstemp.patch):

+ patch -p1 -b --suffix .sec -s

+ echo 'Patch #1 (unix2dos-2.2-segfault.patch):'

Patch #1 (unix2dos-2.2-segfault.patch):

+ patch -p1 -b --suffix .segf -s

+ echo 'Patch #2 (unix2dos-2.2-manpage.patch):'

Patch #2 (unix2dos-2.2-manpage.patch):

+ patch -p1 -b --suffix .man -s

+ perl -pi -e 's,^#endif.*,#endif,g;s,^#else.*,#else,g' unix2dos.c unix2dos.h

+ exit 0

Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.60650

+ umask 022

+ cd /usr/src/redhat/BUILD

+ cd unix2dos-2.2

+ LANG=C

+ export LANG

+ gcc -O2 -march=i386 -mcpu=i686 -ounix2dos unix2dos.c

+ exit 0

Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.35128

+ umask 022

+ cd /usr/src/redhat/BUILD

+ cd unix2dos-2.2

+ LANG=C

+ export LANG

+ rm -rf /var/tmp/unix2dos-root

+ mkdir -p /var/tmp/unix2dos-root/usr/bin /var/tmp/unix2dos-

root/usr/share/man/man1

+ install -m755 unix2dos /var/tmp/unix2dos-root/usr/bin

+ install -m444 unix2dos.1 /var/tmp/unix2dos-root/usr/share/man/man1

+ /usr/lib/rpm/redhat/brp-compress

+ /usr/lib/rpm/redhat/brp-strip

+ /usr/lib/rpm/redhat/brp-strip-comment-note

Processing files: unix2dos-2.2-17

Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.12033

+ umask 022

+ cd /usr/src/redhat/BUILD

+ cd unix2dos-2.2

+ DOCDIR=/var/tmp/unix2dos-root/usr/share/doc/unix2dos-2.2

+ export DOCDIR

+ rm -rf /var/tmp/unix2dos-root/usr/share/doc/unix2dos-2.2

+ /bin/mkdir -p /var/tmp/unix2dos-root/usr/share/doc/unix2dos-2.2

+ cp -pr COPYRIGHT /var/tmp/unix2dos-root/usr/share/doc/unix2dos-2.2

+ exit 0

Finding Provides: /usr/lib/rpm/find-provides

Finding Requires: /usr/lib/rpm/find-requires

PreReq: rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames)

<= 3.0.4-1

Requires(rpmlib): rpmlib(PayloadFilesHavePrefix) <= 4.0-1

rpmlib(CompressedFileNames) <= 3.0.4-1

Requires: libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1)

Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/unix2dos-root

Wrote: /usr/src/redhat/RPMS/i386/unix2dos-2.2-17.i386.rpm

Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.47653

+ umask 022

+ cd /usr/src/redhat/BUILD

+ cd unix2dos-2.2

+ rm -rf /var/tmp/unix2dos-root

+ exit 0

Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.47653

+ umask 022

+ cd /usr/src/redhat/BUILD

+ rm -rf unix2dos-2.2

+ exit 0

With the --rebuild option, the rpmbuild command installs the source RPM for you and then performs the preparation, compile, and installation stages of building a binary RPM. Unless there are errors, you should have a new binary RPM file.

When complete, the rpmbuild --rebuild command cleans out the built files in the build directory, as if the --clean option were used. The rpmbuild --rebuild command also removes the installed sources and spec file upon completion.

Recompiling binaries from source RPMs

If you just want to recompile the files in a source RPM, you can use the --recompile option. The --recompile option tells the rpmbuild command to recompile the binary application from a source RPM.

For example:

rpmbuild --recompile package.src.rpm

This is the same as installing the source RPM and then running rpmbuild -bc --clean with the package spec file.

Note

There is no difference between --recompile and --rebuild in RPM 4.1. RPM 4.2 fixes this problem.

SRPMS? Finding source RPMs

Often, source RPMs are abbreviated as SRPMs. In fact, if you see a directory named SRPM or SRPMS, chances are the directory holds source RPMs. (Red Hat uses this convention for its Linux distributions.)

The SRPMS directories on Red Hat CD-ROMs or on the Red Hat FTP Internet site, ftp.redhat.com, indicate directories that hold source RPMs.

Signing Built RPMs

Signing RPMs adds an extra level of trustworthiness to your RPMs. A digital signature helps establish that the package comes from you, really you, and not from someone masquerading as you. Unfortunately, the RPM system requires a bit of set up work before you can sign RPMs.

Checking that the GPG software is installed

To sign packages, you need to ensure that you have the gpg command installed and configured. To check that this command is installed, use a command like the following:

$ rpm -qf `which gpg`

gnupg-1.0.7-6

This shows that the command is available.

GPG and PGP? Acronyms Explained

The RPM documentation uses GPG and PGP pretty much interchangeably, so much so, in fact, that you may think these are typographical errors. Not so.

PGP stands for Pretty Good Privacy. Invented by Phil Zimmerman, PGP was originally invented to encrypt e-mail to allow for private communication. Based on a public-key cryptography algorithm, PGP also supports encrypted digital signatures. These signatures allow you to verify that a package you have downloaded really comes from the vendor you think it does. You do this by using the vendor’s public key.

GPG stands for GNU Privacy Guard, a free, open-source implementation of PGP from the GNU project. GPG aims to be compatible with the OpenPGP Internet standard as defined in RFC 2440. It started when a number of developers wanted a free implementation. One such free implementation, GPG, allows Linux vendors such as Red Hat to include PGP in their products. So, in a sense, GPG provides PGP.

PGP has a long and somewhat troubled history as an open-source product and as a commercial product. See www.philzimmermann.com for background on PGP and its long history. See www.gnupg.org for more details on GPG.

Configuring a signature

To configure a signature, you first need to create a new key with the gpg command, using the --gen-key option, as shown following:

$ gpg --gen-key

gpg (GnuPG) 1.0.7; Copyright (C) 2002 Free Software Foundation, Inc.

This program comes with ABSOLUTELY NO WARRANTY.

This is free software, and you are welcome to redistribute it

under certain conditions. See the file COPYING for details.

gpg: Warning: using insecure memory!

gpg: please see http://www.gnupg.org/faq.html for more information

gpg: keyring `/home2/ericfj/.gnupg/secring.gpg' created

gpg: keyring `/home2/ericfj/.gnupg/pubring.gpg' created

Please select what kind of key you want:

(1) DSA and ElGamal (default)

(2) DSA (sign only)

(4) ElGamal (sign and encrypt)

(5) RSA (sign only)

Your selection? 1

DSA keypair will have 1024 bits.

About to generate a new ELG-E keypair.

minimum keysize is 768 bits

default keysize is 1024 bits

highest suggested keysize is 2048 bits

What keysize do you want? (1024)

Requested keysize is 1024 bits

Please specify how long the key should be valid.

0 = key does not expire

<n> = key expires in n days

<n>w = key expires in n weeks

<n>m = key expires in n months

<n>y = key expires in n years

Key is valid for? (0)

You need a User-ID to identify your key; the software constructs the user id

from Real Name, Comment and Email Address in this form:

"Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"

Real name: Eric Foster-Johnson

Email address: please_no_spam@nospam.com

Comment: Example for Red Hat RPM Guide

You selected this USER-ID:

"Eric Foster-Johnson (Example for Red Hat RPM Guide) <erc@no_spam.com>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?

O

You need a Passphrase to protect your secret key.

Enter passphrase:

We need to generate a lot of random bytes. It is a good idea to perform

some other action (type on the keyboard, move the mouse, utilize the

disks) during the prime generation; this gives the random number

generator a better chance to gain enough entropy.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+++++++++++++++++++++++++++++++++++..+++++..++++++++++>++++++++++........+++++

gpg: /home2/ericfj/.gnupg/trustdb.gpg: trustdb created

public and secret key created and signed.

key marked as ultimately trusted.

pub 1024D/01681C24 2002-11-05 Eric Foster-Johnson (Example for Red Hat RPM

Guide) <please_no_spam@nospam.com>

Key fingerprint = 8C14 A2E9 47D1 301B 2153 7CDF BEE5 9C10 0268 1D24

sub 1024g/1A15D6C8 2002-11-05

You can choose the default options for most choices. You need to enter a real name, an e-mail address, and a pass phrase. Remember the pass phrase. You will need to enter the pass phrase every time you wish to sign a package.

Once you have a key, the next step is to set up some RPM macros. There are a number of places you can do this, but using the .rpmmacros file in your home directory is one of the easiest. Edit this file as shown in the following example:

%_signature gpg

%_gpg_path /home2/ericfj/.gnupg

%_gpg_name EricFJ (Eric Key) <erc@no_spam.com>

%_gpgbin /usr/bin/gpg

Add lines like these to the $HOME/.rpmmacros file. (Create this file if it does not exist.)

Cross Reference

Chapter 21 covers RPM macros and the $HOME/.rpmmacros file.

Inside the file, change the %gpg_path macro to the .gnupg directory under your home directory (or the root user’s home directory). Change the %_gpg_name macro to the name you have entered into the gpg program.

Signing with the rpmbuild command

The --sign option tells the rpmbuild command to sign the created package. You need to have configured the RPM system for your signature as shown in the previous sections.

When you then build an RPM, you will be prompted for your pass phrase prior to the package build. For example, the following shows this prompt (and truncates the rest of the rpmbuild messages that follow):

$ rpmbuild -bb --sign xtoolwait-1.2.spec

Enter pass phrase:

Pass phrase is good.

Signing with the rpm command

In addition to the --sign option for the rpmbuild command, you can sign packages that have already been created using the rpm command. The --addsign and --resign options generate new signatures and insert them into the passed-in package file. The basic syntax is:

rpm --addsign package.rpm

rpm --resign package.rpm

The --addsign option adds another signature to the RPM. RPM versions prior to 4.1 allowed you to sign a package with multiple keys, which causes problems for automatic verification. Because of that, use the --resign option, which removes the old signature and inserts a new signature into the package.

Verifying signatures

You can verify the RPM signature to ensure that the package has not been modified since it has been signed. Verification also checks that the package is signed by the key that matches the claimed vendor.

To verify the signature in an RPM, use the -K option to the rpm command. The basic syntax is:

rpm -K package.rpm

Note

This is the rpm command, not the rpmbuild command.

This command accepts the options shown in Table 12-3 to turn off checking for certain types of signatures.

Table 12-3 Options to turn off signature checking

Option	Usage
--nogpg	Don’t check for GPG signatures
--nomd5	Don’t check for MD5 signatures
--nopgp	Don’t check for PGP signatures

You can also use the --checksig option, which is the same as -K. When you run this command on a package that has a verifiable key, you will see output like the following:

# rpm -K xtoolwait-1.3-3.src.rpm

xtoolwait-1.3-3.src.rpm: (sha1) dsa sha1 md5 gpg OK

This verifies that the package has not been changed from when it was first signed. It also verifies that the signature matches the public key from the vendor of the package. This goes a long ways toward verifying that the package is indeed legitimate.

To get more information, add a -v (verbose) option. For example:

$ rpm -Kv vixie-cron-3.0.1-69.src.rpm

vixie-cron-3.0.1-69.src.rpm:

Header V3 DSA signature: OK, key ID db42a60e

Header SHA1 digest: OK (ecbb244ab022ecd23114bb1d6c9bdeb74f8d9520)

MD5 digest: OK (fb0a75eca1d526d391c36dc956c23bdd)

V3 DSA signature: OK, key ID db42a60e

If you run this command on a package that does not verify, you’ll see an error like the following:

# rpm --checksig xtoolwait-1.3-3.src.rpm

xtoolwait-1.3-3.src.rpm: (SHA1) DSA sha1 md5 (GPG) NOT OK (MISSING KEYS: GPG#db42a60e)

Items that fail are listed in uppercase, such as DSA, while items that succeed appear in lowercase. In this example, the sha1 and md5 tests succeeded, while the DSA test failed. This failure does not necessarily mean that the package is not legitimate. This failure can mean one of three things:

1.	The package was not properly signed in the first place. That is, it is a legitimate package but the package author did not properly sign the RPM.

2.	The package has been modified in some way. That is, the package is not legitimate.

3.	The RPM system has not been initialized with the public key from the package vendor.

From this error, you don’t yet know whether the package is legitimate or not. The first step, though, is to check that you have imported the proper public key from the package vendor.

Importing public keys

The --import option to the rpm command imports the public key from a given vendor. The format for this key follows:

The following public key can be used to verify RPM packages built and

signed by Red Hat, Inc. using `rpm -K' using the GNU GPG package.

Questions about this key should be sent to security@redhat.com.

-----BEGIN PGP PUBLIC KEY BLOCK-----

Version: GnuPG v1.0.0 (GNU/Linux)

Comment: For info see http://www.gnupg.org

mQGiBDfqVEqRBADBKr3Bl6PO8BQ0H8sJoD6p9U7Yyl7pjtZqioviPwXP+DCWd4u8

HQzcxAZ57m8ssA1LK1Fx93coJhDzM130+p5BG9mYSPShLabR3N1KXdXAYYcowTOM

GxdwYRGr1Spw8QydLhjVfU1VSl4xt6bupPbFJbyjkg5Z3P7BlUOUJmrx3wCgobNV

EDGaWYJcch5z5B1of/41G8kEAKii6q7Gu/vhXXnLS6m15oNnPVybyngiw/23dKjS

ti/PYrrL2J11P2ed0x7zm8v3gLrY0cue1iSba+8glY+p31ZPOr5ogaJw7ZARgoS8

BwjyRymXQp+8Dete0TELKOL2/itDOPGHW07SsVWOR6cmX4VlRRcWB5KejaNvdrE5

4XFtOd04NMgWI63uqZc4zkRa+kwEZtmbz3tHSdWCCE+Y7YVP6IUf/w6YPQFQriWY

FiA6fD10eB+BlIUqIw80EqjsBKmCwvKkn4jg8kibUgj4/TzQSx77uYokw1EqQ2wk

OZoaEtcubsNMquuLCMWijYhGBBgRAgAGBQI36lRyAAoJECGRgM3bQqYOhyYAnj7h

VDY/FJAGqmtZpwVp9IlitW5tAJ4xQApr/jNFZCTksnI+4O1765F7tA==

=3AHZ

-----END PGP PUBLIC KEY BLOCK-----

Note

For reasons of space, this is not a complete key.

You need to pass the name of the text file that holds the key to the rpm --import command, as shown following:

rpm --import key_file

Note

You must be logged in as the root user to import keys.

For example:

# rpm --checksig xtoolwait-1.3-3.src.rpm

xtoolwait-1.3-3.src.rpm: (SHA1) DSA sha1 md5 (GPG) NOT OK (MISSING KEYS: GPG#db42a60e)

# rpm --import RPM-GPG-KEY

# rpm --checksig xtoolwait-1.3-3.src.rpm

xtoolwait-1.3-3.src.rpm: (sha1) dsa sha1 md5 gpg OK

This example shows an error message when trying to verify the key. Then, after importing the Red Hat public key, the verification works.

If, after importing this key, you still have problems, you can assume there are problems with the package. Many administrators will refuse to install such packages.

Warning

You should be careful with packages that have signatures that do not verify.

To list the available keys, use a command like the following:

$ rpm -qa | grep -i gpg

gpg-pubkey-db42a60e-37ea5438

This example shows one key installed.

Note

You can erase this key as if it were a package, using the rpm -e command.

Getting the Red Hat public key

Strangely enough, the Red Hat public key is not installed when you install Red Hat Linux 8.0. If you need the key, the Red Hat public key is available on the root directory of all Red Hat Linux CD-ROMs, as shown in the following listing:

$ ls /mnt/cdrom/

EULA GPL README RedHat/ RPM-GPG-KEY SRPMS/ TRANS.TBL

Simply copy the RPM-GPG-KEY file to get the public key. Then use the rpm --import command with this key file.

Note

You can also download this key file from the Red Hat FTP site, at ftp://ftp.redhat.com/pub/redhat/linux/8.0/en/os/i386/.

Summary

This chapter covers options for the rpmbuild command that allow you to achieve a finer grain of control over how the command works. For example, the --short-circuit option tells the rpmbuild command to build just the stages you ask for. This helps when you have problems in one area of building an RPM and don’t want to start over each time you try to see if the problem is solved.

The rpmbuild command also supports a set of -t options that work like the -b options, except the -t options try to build an RPM from a tar archive of sources (a tarball) instead of an RPM spec file. In this case, the rpmbuild command tries to work without a spec file.

The --rebuild option tells the rpmbuild command to install a source RPM, build the binary RPM, and clean out the installed source RPM. This provides quite a shortcut for installing binary RPMs from source RPMs.

RPMs should be signed to provide an extra level of authentication. This system isn’t perfect, but it helps you verify that a package is from the person it says it is from and that the package has not been modified. You can check the signature on RPM packages you download. You can also, with some configuration, sign the packages you create.

Chapter 12

Chris Ricker

2003-01-29T14:36:00

Eric Foster-Johnson