X-Git-Url: https://git.saurik.com/apt.git/blobdiff_plain/a2d40703e4a5590a689ace4466f92e590434944d..479f6fa454cd6ee9e1bc4d9ecda856d34584092e:/doc/apt-secure.8.xml?ds=sidebyside
diff --git a/doc/apt-secure.8.xml b/doc/apt-secure.8.xml
index e343b86ea..1cf6539c6 100644
--- a/doc/apt-secure.8.xml
+++ b/doc/apt-secure.8.xml
@@ -13,7 +13,7 @@
&apt-email;
&apt-product;
- 2012-06-09T00:00:00Z
+ 2015-10-15T00:00:00Z
@@ -45,32 +45,38 @@
Description
- Starting with version 0.6, apt contains code
- that does signature checking of the Release file for all
- archives. This ensures that packages in the archive can't be
- modified by people who have no access to the Release file signing
- key.
+ Starting with version 0.6, APT contains code that does
+ signature checking of the Release file for all repositories. This ensures
+ that data like packages in the archive can't be modified by people who
+ have no access to the Release file signing key.
- 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. apt-get will currently only warn
- for unsigned archives; future releases might force all sources
- to be verified before downloading packages from them.
+ If an archive has an unsigned Release file or no Release file at all
+ current APT versions will raise a warning in update
+ operations and front-ends like apt-get will require
+ explicit confirmation if an installation request includes a package from
+ such an unauthenticated archive.
- The package frontends &apt-get;, &aptitude; and &synaptic; support this new
- authentication feature.
+ In the future APT will refuse to work with unauthenticated repositories by
+ default until support for them is removed entirely. Users have the option to
+ opt-in to this behavior already by setting the configuration option
+ to false.
+
+
+
+ Note: All APT-based package management front-ends like &apt-get;, &aptitude;
+ and &synaptic; support this authentication feature, so this manpage uses
+ APT to refer to them all for simplicity only.
- Trusted archives
+ Trusted Repositories
-
- The chain of trust from an apt archive to the end user is made up of
+
+ The chain of trust from an APT archive to the end user is made up of
several steps. apt-secure 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
@@ -85,13 +91,14 @@
devscripts packages respectively).
- The chain of trust in Debian starts when a maintainer uploads a new
+ The chain of trust in Debian starts (e.g.) 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
+ contained in one of the Debian package maintainer keyrings (available in
the debian-keyring package). Maintainers' keys are signed by
other maintainers following pre-established procedures to
- ensure the identity of the key holder.
+ ensure the identity of the key holder. Similar procedures exist in all
+ Debian-based distributions.
@@ -132,20 +139,23 @@
However, it does not defend against a compromise of the
- Debian master server itself (which signs the packages) or against a
+ 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.
- User configuration
-
- apt-key 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.
-
+ User Configuration
+ apt-key is the program that manages the list of keys used
+ by APT to trust repositories. It can be used to add or remove keys as well
+ as list the trusted keys. Limiting which key(s) are able to sign which archive
+ is possible via the in &sources-list;.
+
+ Note that a default installation already contains all keys to securely
+ acquire packages from the default repositories, so fiddling with
+ apt-key is only needed if third-party repositories are
+ added.
+
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 apt-key and
@@ -155,7 +165,7 @@
-Archive configuration
+Archive Configuration
If you want to provide archive signatures in an archive under your
maintenance you have to:
@@ -171,10 +181,21 @@
gpg --clearsign -o InRelease Release and
gpg -abs -o Release.gpg Release.
- Publish the key fingerprint,
- that way your users will know what key they need to import in
- order to authenticate the files in the
- archive.
+
+ Publish the key fingerprint, so that your users
+ will know what key they need to import in order to authenticate the files
+ in the archive. It is best to ship your key in its own keyring package
+ like &keyring-distro; does with &keyring-package; to be able to
+ distribute updates and key transitions automatically later.
+
+
+
+ Provide instructions on how to add your archive and key.
+ If your users can't acquire your key securely the chain of trust described above is broken.
+ How you can help users add your key depends on your archive and target audience ranging
+ from having your keyring package included in another archive users already have configured
+ (like the default repositories of their distribution) to leveraging the web of trust.
+
@@ -192,9 +213,9 @@
For more background information you might want to review the
Debian
+url="https://www.debian.org/doc/manuals/securing-debian-howto/ch7">Debian
Security Infrastructure chapter of the Securing Debian Manual
-(available also in the harden-doc package) and the
+(also available in the harden-doc package) and the
Strong Distribution HOWTO by V. Alex Brennen.
@@ -213,4 +234,3 @@ Peña, Isaac Jones, Colin Walters, Florian Weimer and Michael Vogt.
-