X-Git-Url: https://git.saurik.com/apt.git/blobdiff_plain/fce69e7a0f38299c57ef96ae1c1dd9a5379bfd5a..8b21456acba3cbbc28f35eba684d8f21b0c290b4:/doc/apt-secure.8.xml diff --git a/doc/apt-secure.8.xml b/doc/apt-secure.8.xml index 981351615..75c4dc61e 100644 --- a/doc/apt-secure.8.xml +++ b/doc/apt-secure.8.xml @@ -1,15 +1,9 @@ -%aptent; - - -%aptverbatiment; - - -%aptvendor; + %aptent; + %aptverbatiment; + %aptvendor; ]> @@ -19,7 +13,7 @@ &apt-email; &apt-product; - 2012-06-09T00:00:00Z + 2016-07-07T00:00:00Z @@ -51,32 +45,66 @@ 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. Starting with version 1.1 + APT requires repositories to provide recent authentication + information for unimpeded usage of the repository. + + + + If an archive has an unsigned Release file or no Release file at all + current APT versions will refuse to download data from them by default + in update operations and even if forced to download + front-ends like &apt-get; will require explicit confirmation if an + installation request includes a package from such an unauthenticated + archive. + + + + As a temporary exception &apt-get; (not &apt;!) raises warnings only if it + encounters unauthenticated archives to give a slightly longer grace period + on this backward compatibility effecting change. This exception will be removed + in future releases and you can opt-out of this grace period by setting the + configuration option + to false or + on the command line. + + + + You can force all APT clients to raise only warnings by setting the + configuration option to + true. Individual repositories can also be allowed to be insecure + via the &sources-list; option allow-insecure=yes. + Note that insecure repositories are strongly discouraged and all options + to force apt to continue supporting them will eventually be removed. + Users also have the option available to disable + even the warnings, but be sure to understand the implications as detailed in + &sources-list;. - 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. + A repository which previously was authentication but would loose this state in + an update operation raises an error in all APT clients + irrespective of the option to allow or forbid usage of insecure repositories. + The error can be overcome by additionally setting + + to true or for Individual repositories with the &sources-list; + option allow-downgrade-to-insecure=yes. - The package frontends &apt-get;, &aptitude; and &synaptic; support this new - authentication feature. + 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 @@ -91,13 +119,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. @@ -138,20 +167,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 @@ -161,7 +193,7 @@ -Archive configuration +Archive Configuration If you want to provide archive signatures in an archive under your maintenance you have to: @@ -177,10 +209,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. + @@ -193,14 +236,14 @@ See Also &apt-conf;, &apt-get;, &sources-list;, &apt-key;, &apt-ftparchive;, -&debsign; &debsig-verify;, &gpg; +&debsign;, &debsig-verify;, &gpg; 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. @@ -219,4 +262,3 @@ Peña, Isaac Jones, Colin Walters, Florian Weimer and Michael Vogt. -