X-Git-Url: https://git.saurik.com/apt.git/blobdiff_plain/16d7341fce96b089aa2a1c241acd0a72209bcd7f..5419a6ce20967902102358a07632ae3688788d62:/doc/apt-secure.8.xml diff --git a/doc/apt-secure.8.xml b/doc/apt-secure.8.xml index 20f473f77..1cf6539c6 100644 --- a/doc/apt-secure.8.xml +++ b/doc/apt-secure.8.xml @@ -1,15 +1,21 @@ - -%aptent; - + %aptent; + %aptverbatiment; + %aptvendor; ]> - &apt-docinfo; - + + &apt-author.jgunthorpe; + &apt-author.team; + &apt-email; + &apt-product; + + 2015-10-15T00:00:00Z + + apt-secure 8 @@ -39,37 +45,43 @@ 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 - different steps. apt-secure is the last step in - this chain, trusting an archive does not mean that the packages - that you trust it do not contain malicious code but means that you - trust the archive maintainer. Its the archive maintainer - responsibility to ensure that the archive integrity is correct. + + 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 + trust the archive maintainer. It's the archive maintainer's + responsibility to ensure that the archive's integrity is preserved. apt-secure does not review signatures at a @@ -79,31 +91,31 @@ devscripts packages respectively). - 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. This - upload in order to become effective needs to be signed by a key of - a maintainer within the Debian maintainer's keyring (available in - the debian-keyring package). Maintainer's keys are signed by + 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 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. Once the uploaded package is verified and included in the archive, - the maintainer signature is stripped off, an MD5 sum of the package - is computed and put in the Packages file. The MD5 sum 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 (which is created - once a year and distributed through the FTP server. This key is - also on the Debian keyring. + 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 &keyring-distro; release, + and distributed alongside the packages and the Packages files on + &keyring-distro; mirrors. The keys are in the &keyring-distro; archive keyring + available in the &keyring-package; package. - Any end user can check the signature of the Release file, extract the MD5 - sum of a package from it and compare it with the MD5 sum of the - package he downloaded. Prior to version 0.6 only the MD5 sum of the - downloaded Debian package was checked. Now both the MD5 sum and the - signature of the Release file are checked. + 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. Notice that this is distinct from checking signatures on a @@ -112,11 +124,11 @@ Network "man in the middle" - attacks. Without signature checking, a malicious - agent can introduce himself in the package download process and + 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 + rogue server (through ARP or DNS spoofing attacks). Mirror network compromise. @@ -127,68 +139,83 @@ 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 provide 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 then run apt-get update so that apt can download - and verify the Release.gpg files from the archives you - have configured. + and verify the InRelease or Release.gpg + files from the archives you have configured. -Archive configuration +Archive Configuration If you want to provide archive signatures in an archive under your maintenance you have to: - Create a toplevel Release - file. if it does not exist already. You can do this + Create a toplevel Release + file, if it does not exist already. You can do this by running apt-ftparchive release (provided in apt-utils). - Sign it. You can do this by running + Sign it. You can do this by running + 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. + - Whenever the contents of the archive changes (new packages + Whenever the contents of the archive change (new packages are added or removed) the archive maintainer has to follow the - first two steps previously outlined. + first two steps outlined above. 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. @@ -207,4 +234,3 @@ Peña, Isaac Jones, Colin Walters, Florian Weimer and Michael Vogt. -