0241-0244.html
来自「linux-unix130.linux.and.unix.ebooks130 l」· HTML 代码 · 共 380 行
HTML
380 行
<HTML>
<HEAD>
<TITLE>Maximum RPM (RPM):Adding PGP Signatures to a Package:EarthWeb Inc.-</TITLE>
<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
<SCRIPT>
<!--
function displayWindow(url, width, height) {
var Win = window.open(url,"displayWindow",'width=' + width +
',height=' + height + ',resizable=1,scrollbars=yes');
}
//-->
</SCRIPT>
</HEAD>
-->
<!-- ISBN=0672311054 //-->
<!-- TITLE=Maximum RPM (RPM)//-->
<!-- AUTHOR=Edward Bailey//-->
<!-- PUBLISHER=Macmillan Computer Publishing//-->
<!-- IMPRINT=Sams//-->
<!-- CHAPTER=17 //-->
<!-- PAGES=0237-0246 //-->
<!-- UNASSIGNED1 //-->
<!-- UNASSIGNED2 //-->
<P><CENTER>
<a href="0237-0240.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0245-0246.html">Next</A>
</CENTER></P>
<A NAME="PAGENUM-241"><P>Page 241</P></A>
<UL>
<LI>
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:
<!-- CODE SNIP //-->
<PRE>
pgp_name: Example Key for RPM Book
</PRE>
<!-- END CODE SNIP //-->
<LI>
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:
<!-- CODE SNIP //-->
<PRE>
pgp_path: /root/.pgp
</PRE>
<!-- END CODE SNIP //-->
</UL>
<P>And that's it. Now it's time to sign some packages.
</P>
<H3><A NAME="ch17_ 6">
17.3. Signing Packages
</A></H3>
<P>There are three different ways to sign a package:
</P>
<UL>
<LI> Sign the package at build time.
<LI> Replace the signature on an already-existing package.
<LI> Add a signature to an already-existing package.
</UL>
<P>Let's take a look at each one, starting with build time signing.
</P>
<H4><A NAME="ch17_ 7">
17.3.1. --sign: Sign a Package at Build Time
</A></H4>
<P>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.
</P>
<P>Here's an example of --sign in action:
</P>
<!-- CODE //-->
<PRE>
# 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
#
</PRE>
<!-- END CODE //-->
<A NAME="PAGENUM-242"><P>Page 242</P></A>
<P>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.)
</P>
<P>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.
</P>
<P>If we issue a quick signature check using RPM's
--checksig option, we can see that there is, in fact, a PGP signature present:
</P>
<!-- CODE SNIP //-->
<PRE>
# rpm --checksig blather-7.9-1.i386.rpm
blather-7.9-1.i386.rpm: size pgp md5 OK
#
</PRE>
<!-- END CODE SNIP //-->
<P>It's clear that, in addition to the usual size and MD5 signatures, the package has a PGP
signature.
</P>
<H4><A NAME="ch17_ 8">
17.3.1.1. Multiple Builds? No Problem!
</A></H4>
<P>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:
</P>
<!-- CODE //-->
<PRE>
# 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
#
</PRE>
<!-- END CODE //-->
<A NAME="PAGENUM-243"><P>Page 243</P></A>
<P>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.
</P>
<H4><A NAME="ch17_ 9">
17.3.2. --resign: Replace a Package's Signature(s)
</A></H4>
<P>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.
</P>
<P>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:
</P>
<!-- CODE //-->
<PRE>
# rpm --resign blather-7.9-1.i386.rpm
Enter pass phrase: <passphrase> (Not echoed)
Pass phrase is good.
blather-7.9-1.i386.rpm:
#
</PRE>
<!-- END CODE //-->
<P>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.
</P>
<P>As you might have guessed, the --resign option works properly on multiple package files:
</P>
<!-- CODE //-->
<PRE>
# 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:
#
</PRE>
<!-- END CODE //-->
<H4><A NAME="ch17_ 10">
17.3.2.1. There Are Limits, However…
</A></H4>
<P>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:
</P>
<!-- CODE //-->
<PRE>
# 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
#
</PRE>
<!-- END CODE //-->
<P>Not sure what version your package files are in? Just use the
file command to check:
</P>
<!-- CODE SNIP //-->
<PRE>
# file blather-7.9-1.i386.rpm
blather-7.9-1.i386.rpm: RPM v3 bin i386 blather-7.9-1
#
</PRE>
<!-- END CODE SNIP //-->
<P>The v3 in file's output indicates the package file format.
</P>
<A NAME="PAGENUM-244"><P>Page 244</P></A>
<H4><A NAME="ch17_ 11">
17.3.3. --addsign: Add a Signature to a Package
</A></H4>
<P>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?
</P>
<P>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.
</P>
<P>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.
</P>
<P>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.
</P>
<P>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.
</P>
<P>After this lengthy example, the actual output from the
--addsign option is a bit anticlimactic:
</P>
<!-- CODE //-->
<PRE>
# rpm --addsign blather-7.9-1.i386.rpm
Enter pass phrase: <passphrase> (Not echoed)
Pass phrase is good.
blather-7.9-1.i386.rpm:
#
</PRE>
<!-- END CODE //-->
<P>If we check the signatures of this package, we'll be able to see the multiple signatures:
</P>
<!-- CODE SNIP //-->
<PRE>
# rpm --checksig blather-7.9-1.i386.rpm
blather-7.9-1.i386.rpm: size pgp pgp md5 OK
#
</PRE>
<!-- END CODE SNIP //-->
<P>The two pgps in --checksig's output clearly show that the package has been signed twice.
</P>
<H4><A NAME="ch17_ 12">
17.3.3.1. A Few Caveats
</A></H4>
<P>As with the --resign option, the --addsign option cannot do its magic on pre-version 3
package files:
</P>
<!-- CODE //-->
<PRE>
# 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
#
</PRE>
<!-- END CODE //-->
<P><CENTER>
<a href="0237-0240.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0245-0246.html">Next</A>
</CENTER></P>
</td>
</tr>
</table>
<!-- begin footer information -->
</body></html>⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?