1 <?xml version=
"1.0" encoding=
"utf-8" standalone=
"no"?>
2 <!DOCTYPE refentry PUBLIC
"-//OASIS//DTD DocBook XML V4.5//EN"
3 "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
5 <!ENTITY % aptent SYSTEM
"apt.ent">
8 <!ENTITY % aptverbatiment SYSTEM
"apt-verbatim.ent">
11 <!ENTITY % aptvendor SYSTEM
"apt-vendor.ent">
17 &apt-author.jgunthorpe;
21 <!-- The last update date -->
22 <date>2012-
06-
09T00:
00:
00Z
</date>
26 <refentrytitle>apt-secure
</refentrytitle>
27 <manvolnum>8</manvolnum>
28 <refmiscinfo class=
"manual">APT
</refmiscinfo>
31 <!-- NOTE: This manpage has been written based on the
32 Securing Debian Manual ("Debian Security
33 Infrastructure" chapter) and on documentation
34 available at the following sites:
35 http://wiki.debian.net/?apt06
36 http://www.syntaxpolice.org/apt-secure/
37 http://www.enyo.de/fw/software/apt-secure/
39 <!-- TODO: write a more verbose example of how it works with
41 http://www.debian-administration.org/articles/174
46 <!-- Man page title -->
48 <refname>apt-secure
</refname>
49 <refpurpose>Archive authentication support for APT
</refpurpose>
52 <refsect1><title>Description
</title>
54 Starting with version
0.6,
<command>apt
</command> contains code
55 that does signature checking of the Release file for all
56 archives. This ensures that packages in the archive can't be
57 modified by people who have no access to the Release file signing
62 If a package comes from a archive without a signature, or with a
63 signature that apt does not have a key for, that package is
64 considered untrusted, and installing it will result in a big
65 warning.
<command>apt-get
</command> will currently only warn
66 for unsigned archives; future releases might force all sources
67 to be verified before downloading packages from them.
71 The package frontends &apt-get;,
&aptitude; and
&synaptic; support this new
72 authentication feature.
76 <refsect1><title>Trusted archives
</title>
79 The chain of trust from an apt archive to the end user is made up of
80 several steps.
<command>apt-secure
</command> is the last step in
81 this chain; trusting an archive does not mean that you trust its
82 packages not to contain malicious code, but means that you
83 trust the archive maintainer. It's the archive maintainer's
84 responsibility to ensure that the archive's integrity is preserved.
87 <para>apt-secure does not review signatures at a
88 package level. If you require tools to do this you should look at
89 <command>debsig-verify
</command> and
90 <command>debsign
</command> (provided in the debsig-verify and
91 devscripts packages respectively).
</para>
94 The chain of trust in Debian starts when a maintainer uploads a new
95 package or a new version of a package to the Debian archive. In
96 order to become effective, this upload needs to be signed by a key
97 contained in the Debian Maintainers keyring (available in
98 the debian-keyring package). Maintainers' keys are signed by
99 other maintainers following pre-established procedures to
100 ensure the identity of the key holder.
104 Once the uploaded package is verified and included in the archive,
105 the maintainer signature is stripped off, and checksums of the package
106 are computed and put in the Packages file. The checksums of all of the
107 Packages files are then computed and put into the Release file. The
108 Release file is then signed by the archive key for this &keyring-distro; release,
109 and distributed alongside the packages and the Packages files on
110 &keyring-distro; mirrors. The keys are in the &keyring-distro; archive keyring
111 available in the &keyring-package; package.
115 End users can check the signature of the Release file, extract a checksum
116 of a package from it and compare it with the checksum of the package
117 they downloaded by hand - or rely on APT doing this automatically.
120 <para>Notice that this is distinct from checking signatures on a
121 per package basis. It is designed to prevent two possible attacks:
125 <listitem><para><literal>Network "man in the middle"
126 attacks
</literal>. Without signature checking, malicious
127 agents can introduce themselves into the package download process and
128 provide malicious software either by controlling a network
129 element (router, switch, etc.) or by redirecting traffic to a
130 rogue server (through ARP or DNS spoofing
131 attacks).
</para></listitem>
133 <listitem><para><literal>Mirror network compromise
</literal>.
134 Without signature checking, a malicious agent can compromise a
135 mirror host and modify the files in it to propagate malicious
136 software to all users downloading packages from that
137 host.
</para></listitem>
140 <para>However, it does not defend against a compromise of the
141 Debian master server itself (which signs the packages) or against a
142 compromise of the key used to sign the Release files. In any case,
143 this mechanism can complement a per-package signature.
</para>
146 <refsect1><title>User configuration
</title>
148 <command>apt-key
</command> is the program that manages the list
149 of keys used by apt. It can be used to add or remove keys, although
150 an installation of this release will automatically contain the
151 default Debian archive signing keys used in the Debian package
155 In order to add a new key you need to first download it
156 (you should make sure you are using a trusted communication channel
157 when retrieving it), add it with
<command>apt-key
</command> and
158 then run
<command>apt-get update
</command> so that apt can download
159 and verify the
<filename>InRelease
</filename> or
<filename>Release.gpg
</filename>
160 files from the archives you have configured.
164 <refsect1><title>Archive configuration
</title>
166 If you want to provide archive signatures in an archive under your
167 maintenance you have to:
171 <listitem><para><emphasis>Create a toplevel Release
172 file
</emphasis>, if it does not exist already. You can do this
173 by running
<command>apt-ftparchive release
</command>
174 (provided in apt-utils).
</para></listitem>
176 <listitem><para><emphasis>Sign it
</emphasis>. You can do this by running
177 <command>gpg --clearsign -o InRelease Release
</command> and
178 <command>gpg -abs -o Release.gpg Release
</command>.
</para></listitem>
180 <listitem><para><emphasis>Publish the key fingerprint
</emphasis>,
181 that way your users will know what key they need to import in
182 order to authenticate the files in the
183 archive.
</para></listitem>
187 <para>Whenever the contents of the archive change (new packages
188 are added or removed) the archive maintainer has to follow the
189 first two steps outlined above.
</para>
193 <refsect1><title>See Also
</title>
195 &apt-conf;, &apt-get;, &sources-list;, &apt-key;, &apt-ftparchive;,
196 &debsign; &debsig-verify;,
&gpg;
199 <para>For more background information you might want to review the
201 url=
"http://www.debian.org/doc/manuals/securing-debian-howto/ch7">Debian
202 Security Infrastructure
</ulink> chapter of the Securing Debian Manual
203 (available also in the harden-doc package) and the
204 <ulink url=
"http://www.cryptnet.net/fdp/crypto/strong_distro.html"
205 >Strong Distribution HOWTO
</ulink> by V. Alex Brennen.
</para>
212 <refsect1><title>Manpage Authors
</title>
214 <para>This man-page is based on the work of Javier Fernández-Sanguino
215 Peña, Isaac Jones, Colin Walters, Florian Weimer and Michael Vogt.