• pgp_name—The pgp_name entry gives RPM the user ID of the key it is to sign packages with. In our key-generation example, the user ID of the key we created was Example Key for RPM Book, so this is what our entry should look like:

  
  pgp_name: Example Key for RPM Book
  
  

• pgp_path—The pgp_path entry is used to define the path to the directory where the keys are kept. This entry is not needed if the environment variable PGPPATH has been defined. In our example, we didn't move them from PGP's default location, which is in the subdirectory .pgp, off the user's login directory. Because we generated the key as root, our path is /root/.pgp. Therefore, our entry would look like this:

  
  pgp_path: /root/.pgp
  
  

And that's it. Now it's time to sign some packages.

17.3. Signing Packages

There are three different ways to sign a package:

• Sign the package at build time.
• Replace the signature on an already-existing package.
• Add a signature to an already-existing package.

Let's take a look at each one, starting with build time signing.

17.3.1. --sign: Sign a Package at Build Time

The --sign option is used to sign a package as it is being built. When this option is added to an RPM build command, RPM will ask for your PGP passphrase. If the passphrase is correct, the build will proceed. If not, the build stops immediately.

Here's an example of --sign in action:

# rpm -ba --sign blather-7.9.spec

Enter pass phrase: <passphrase> (Not echoed)



Pass phrase is good.

* Package: blather

...

Binary  Packaging:  blather-7.9-1

Finding  dependencies...

...

Generating  signature:  1002

Wrote:          /usr/src/redhat/RPMS/i386/blather-7.9-1.i386.rpm

...

Source  Packaging:   blather-7.9-1

...

Generating  signature:  1002

Wrote:          /usr/src/redhat/SRPMS/blather-7.9-1.src.rpm

#

Once the passphrase is entered, there's very little that is different from a normal build. The only obvious difference is the Generating signature message in both the binary and source packaging sections. The number following the message indicates that the signature added was created using PGP. (The list of possible signature types can be found in the RPM sources, specifically signature.h, in RPM's lib subdirectory.)

Notice that since RPM only signs the source and binary package files, only the -bb and -ba options make any sense when used with --sign. This is due to the fact that only the -bb and -ba options create package files.

If we issue a quick signature check using RPM's --checksig option, we can see that there is, in fact, a PGP signature present:

# rpm --checksig blather-7.9-1.i386.rpm

blather-7.9-1.i386.rpm: size pgp md5 OK

#

It's clear that, in addition to the usual size and MD5 signatures, the package has a PGP signature.

17.3.1.1. Multiple Builds? No Problem!

You might be wondering how the --sign option will work if more than one package is to be built. Do you have to enter the passphrase for every single package you build? The answer is no, as long as you build the packages with a single RPM command. Here's an example:

# rpm -ba --sign b*.spec

Enter pass phrase: <passphrase> (Not echoed)



Pass phrase is good.

* Package: blather

...

Binary  Packaging:  blather-7.9-1

...

Generating signature: 1002

Wrote:           /usr/src/redhat/RPMS/i386/blather-7.9-1.i386.rpm

...

Source   Packaging:  blather-7.9-1

...

Generating signature: 1002

Wrote:           /usr/src/redhat/SRPMS/blather-7.9-1.src.rpm

...

* Package:  bother

...

Binary  Packaging:  bother-3.5-1

...

Generating signature: 1002

Wrote:           /usr/src/redhat/RPMS/i386/bother-3.5-1.i386.rpm

...

Source   Packaging:   bother-3.5-1

...

Generating  signature:  1002

Wrote:            /usr/src/redhat/SRPMS/bother-3.5-1.src.rpm

#

Using the --sign option makes it as easy to sign one package as it is to sign 100. But what happens if you need to change your public key? Will you need to rebuild every single one of your packages just to update the signature? No, because there's an easy way out that we'll explore in the next section.

17.3.2. --resign: Replace a Package's Signature(s)

As mentioned at the end of the previous section, from time to time it may be necessary to change your public key. Certainly this would be necessary if your key's security were compromised, but other, more mundane situations might require this.

Fortunately, RPM has an option that permits you to replace the signature on an already-built package with a new one. The option is called --resign. Here's an example of its use:

#   rpm  --resign  blather-7.9-1.i386.rpm

Enter  pass  phrase:    <passphrase>  (Not echoed)



Pass  phrase  is  good.

blather-7.9-1.i386.rpm:

#

While the output is not as exciting as a package build, the --resign option can be a lifesaver if you need to change a package's signature and you don't want to rebuild.

As you might have guessed, the --resign option works properly on multiple package files:

# rpm --resign b*.rpm

Enter pass phrase: <passphrase> (Not echoed)



Pass  phrase  is  good.

blather-7.9-1.i386.rpm:

bother-3.5-1.i386.rpm:

#

17.3.2.1. There Are Limits, However…

Unfortunately, older package files cannot be re-signed. The package file must be in version 3 format, at least. If you attempt to re-sign a package that is too old, here's what you'll see:

# rpm --resign blah.rpm

Enter pass phrase: <passphrase> (Not echoed)



Pass phrase is good.

blah.rpm:

blah.rpm: Can't re-sign v2.0 RPM

#

Not sure what version your package files are in? Just use the file command to check:

#  file   blather-7.9-1.i386.rpm

blather-7.9-1.i386.rpm: RPM v3 bin i386 blather-7.9-1

#

The v3 in file's output indicates the package file format.

17.3.3. --addsign: Add a Signature to a Package

The --addsign option, as the name suggests, is used to add another signature to the package. It's pretty easy to see why someone would want to have a package that had been signed by the package builders. But what reason would there be for adding a signature to a package?

One reason to have more than one signature on a package would be to provide a means of documenting the path of ownership from the package builder to the end user.

As an example, one division of a company creates a package and signs it with the division's key. The company's headquarters then checks the package's signature and adds the corporate signature to the package, in essence stating that the signed package it received is authentic.

Continuing the example, the doubly signed package makes its way to a retailer. The retailer checks the package's signatures and, when they check out, adds its signature to the package.

The package now makes its way to a company that wants to deploy the package. After checking every signature on the package, it knows that it is an authentic copy, unchanged since it was first created. Depending on the deploying company's internal controls, it may choose to add its own signature, thereby reassuring its employees that the package has received its corporate blessing.

After this lengthy example, the actual output from the --addsign option is a bit anticlimactic:

#  rpm   --addsign   blather-7.9-1.i386.rpm

Enter  pass  phrase:   <passphrase>  (Not echoed)



Pass  phrase  is  good.

blather-7.9-1.i386.rpm:

#

If we check the signatures of this package, we'll be able to see the multiple signatures:

#  rpm  --checksig  blather-7.9-1.i386.rpm

blather-7.9-1.i386.rpm: size pgp pgp md5 OK

#

The two pgps in --checksig's output clearly show that the package has been signed twice.

17.3.3.1. A Few Caveats

As with the --resign option, the --addsign option cannot do its magic on pre-version 3 package files:

# rpm --addsign blah.rpm

Enter  pass  phrase: <passphrase> (Not echoed)



Pass phrase is good.

blah.rpm:

blah.rpm: Can't re-sign v2.0 RPM

#