Библиотека сайта rus-linux.net
| Maximum RPM: Taking the Red Hat Package Manager to the Limit | ||
|---|---|---|
| Prev | Chapter 17. Adding PGP Signatures to a Package | Next |
Signing Packages
There are three different ways to sign a package:
Signing a package at build-time.
Replacing the signature on an already-existing package.
Adding a signature to an already-existing package.
Lets take a look at each one, starting with build-time signing.
--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 pass phrase. If the pass phrase is correct, the build will proceed. If not, the build stops immediately.
|
Once the pass phrase 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.
[1]
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.
|
It's clear to see that, in addition to the usual size and MD5 signatures, the package has a PGP signature.
Multiple Builds? No Problem!
|
Using the --sign option makes it as easy to sign one package as it is to sign one hundred. 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?
--resign — Replace a Package's Signature(s)
As we 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 was compromised, but other, more mundane situations might require this.
|
While the output is not as exciting as a package build, the --resign option can be a life-saver if you need to change a package's signature, and you don't want to rebuild.
|
There Are Limits, However…
|
|
The "v3" in
file's output indicates the package file format.
--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, the 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 received by them 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 their signature to the package.
The package now makes its way to a company that wishes to deploy the package. After checking every signature on the package, they know that it is an authentic copy, unchanged since it was first created. Depending on the deploying company's internal controls, they may choose to add their own signature, thereby reassuring their employees that the package has received their corporate "blessing".
|
|
The two pgp's in
--checksig's output clearly shows that the package
has been signed twice.
A Few Caveats
|
OK, the error message may not be 100% accurate, but you get the idea.
|
As we can see from --checksig's output, the package now has four identical signatures. Maybe this is the digital equivalent of pressing down extra hard while writing your name…
Notes
| [1] | The list of possible signature types can be found in the RPM
sources, specifically |