'\" t
.\"     Title: apt-secure
.\"    Author: Jason Gunthorpe
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
.\"      Date: 09\ \&June\ \&2012
.\"    Manual: APT
.\"    Source: APT 1.0.9.8.4
.\"  Language: English
.\"
.TH "APT\-SECURE" "8" "09\ \&June\ \&2012" "APT 1.0.9.8.4" "APT"
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------
.SH "NAME"
apt-secure \- Archive authentication support for APT
.SH "DESCRIPTION"
.PP
Starting with version 0\&.6,
\fBapt\fR
contains code that does signature checking of the Release file for all archives\&. This ensures that packages in the archive can\*(Aqt be modified by people who have no access to the Release file signing key\&.
.PP
If a package comes from a archive without a signature, or with a signature that apt does not have a key for, that package is considered untrusted, and installing it will result in a big warning\&.
\fBapt\-get\fR
will currently only warn for unsigned archives; future releases might force all sources to be verified before downloading packages from them\&.
.PP
The package frontends
\fBapt-get\fR(8),
\fBaptitude\fR(8)
and
\fBsynaptic\fR(8)
support this new authentication feature\&.
.SH "TRUSTED ARCHIVES"
.PP
The chain of trust from an apt archive to the end user is made up of several steps\&.
\fBapt\-secure\fR
is the last step in this chain; trusting an archive does not mean that you trust its packages not to contain malicious code, but means that you trust the archive maintainer\&. It\*(Aqs the archive maintainer\*(Aqs responsibility to ensure that the archive\*(Aqs integrity is preserved\&.
.PP
apt\-secure does not review signatures at a package level\&. If you require tools to do this you should look at
\fBdebsig\-verify\fR
and
\fBdebsign\fR
(provided in the debsig\-verify and devscripts packages respectively)\&.
.PP
The chain of trust in Debian starts when a maintainer uploads a new package or a new version of a package to the Debian archive\&. In order to become effective, this upload needs to be signed by a key contained in the Debian Maintainers keyring (available in the debian\-keyring package)\&. Maintainers\*(Aq keys are signed by other maintainers following pre\-established procedures to ensure the identity of the key holder\&.
.PP
Once the uploaded package is verified and included in the archive, the maintainer signature is stripped off, and checksums of the package are computed and put in the Packages file\&. The checksums of all of the Packages files are then computed and put into the Release file\&. The Release file is then signed by the archive key for this Debian release, and distributed alongside the packages and the Packages files on Debian mirrors\&. The keys are in the Debian archive keyring available in the
debian\-archive\-keyring
package\&.
.PP
End users can check the signature of the Release file, extract a checksum of a package from it and compare it with the checksum of the package they downloaded by hand \- or rely on APT doing this automatically\&.
.PP
Notice that this is distinct from checking signatures on a per package basis\&. It is designed to prevent two possible attacks:
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Network "man in the middle" attacks\&. Without signature checking, malicious agents can introduce themselves into the package download process and provide malicious software either by controlling a network element (router, switch, etc\&.) or by redirecting traffic to a rogue server (through ARP or DNS spoofing attacks)\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Mirror network compromise\&. Without signature checking, a malicious agent can compromise a mirror host and modify the files in it to propagate malicious software to all users downloading packages from that host\&.
.RE
.PP
However, it does not defend against a compromise of the Debian master server itself (which signs the packages) or against a compromise of the key used to sign the Release files\&. In any case, this mechanism can complement a per\-package signature\&.
.SH "USER CONFIGURATION"
.PP
\fBapt\-key\fR
is the program that manages the list of keys used by apt\&. It can be used to add or remove keys, although an installation of this release will automatically contain the default Debian archive signing keys used in the Debian package repositories\&.
.PP
In order to add a new key you need to first download it (you should make sure you are using a trusted communication channel when retrieving it), add it with
\fBapt\-key\fR
and then run
\fBapt\-get update\fR
so that apt can download and verify the
InRelease
or
Release\&.gpg
files from the archives you have configured\&.
.SH "ARCHIVE CONFIGURATION"
.PP
If you want to provide archive signatures in an archive under your maintenance you have to:
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fICreate a toplevel Release file\fR, if it does not exist already\&. You can do this by running
\fBapt\-ftparchive release\fR
(provided in apt\-utils)\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fISign it\fR\&. You can do this by running
\fBgpg \-\-clearsign \-o InRelease Release\fR
and
\fBgpg \-abs \-o Release\&.gpg Release\fR\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fIPublish the key fingerprint\fR, that way your users will know what key they need to import in order to authenticate the files in the archive\&.
.RE
.PP
Whenever the contents of the archive change (new packages are added or removed) the archive maintainer has to follow the first two steps outlined above\&.
.SH "SEE ALSO"
.PP
\fBapt.conf\fR(5),
\fBapt-get\fR(8),
\fBsources.list\fR(5),
\fBapt-key\fR(8),
\fBapt-ftparchive\fR(1),
\fBdebsign\fR(1),
\fBdebsig-verify\fR(1),
\fBgpg\fR(1)
.PP
For more background information you might want to review the
\m[blue]\fBDebian Security Infrastructure\fR\m[]\&\s-2\u[1]\d\s+2
chapter of the Securing Debian Manual (available also in the harden\-doc package) and the
\m[blue]\fBStrong Distribution HOWTO\fR\m[]\&\s-2\u[2]\d\s+2
by V\&. Alex Brennen\&.
.SH "BUGS"
.PP
\m[blue]\fBAPT bug page\fR\m[]\&\s-2\u[3]\d\s+2\&. If you wish to report a bug in APT, please see
/usr/share/doc/debian/bug\-reporting\&.txt
or the
\fBreportbug\fR(1)
command\&.
.SH "AUTHOR"
.PP
APT was written by the APT team
<apt@packages\&.debian\&.org>\&.
.SH "MANPAGE AUTHORS"
.PP
This man\-page is based on the work of Javier Fernández\-Sanguino Peña, Isaac Jones, Colin Walters, Florian Weimer and Michael Vogt\&.
.SH "AUTHORS"
.PP
\fBJason Gunthorpe\fR
.RS 4
.RE
.PP
\fBAPT team\fR
.RS 4
.RE
.SH "NOTES"
.IP " 1." 4
Debian Security Infrastructure
.RS 4
\%http://www.debian.org/doc/manuals/securing-debian-howto/ch7
.RE
.IP " 2." 4
Strong Distribution HOWTO
.RS 4
\%http://www.cryptnet.net/fdp/crypto/strong_distro.html
.RE
.IP " 3." 4
APT bug page
.RS 4
\%http://bugs.debian.org/src:apt
.RE