{
    "mode": "info",
    "parameter": "APT-SECURE",
    "section": "",
    "url": "https://www.chedong.com/phpMan.php/info/APT-SECURE/json",
    "generated": "2026-08-04T05:45:25Z",
    "sections": {
        "NAME": {
            "content": "apt-secure - Archive authentication support for APT\n",
            "subsections": []
        },
        "DESCRIPTION": {
            "content": "Starting with version 0.6, APT contains code that does signature\nchecking of the Release file for all repositories. This ensures that\ndata like packages in the archive can't be modified by people who have\nno access to the Release file signing key. Starting with version 1.1\nAPT requires repositories to provide recent authentication information\nfor unimpeded usage of the repository. Since version 1.5 changes in the\ninformation contained in the Release file about the repository need to\nbe confirmed before APT continues to apply updates from this\nrepository.\n\nNote: All APT-based package management front-ends like apt-get(8),\naptitude(8) and synaptic(8) support this authentication feature, so\nthis manpage uses APT to refer to them all for simplicity only.\n",
            "subsections": []
        },
        "UNSIGNED REPOSITORIES": {
            "content": "If an archive has an unsigned Release file or no Release file at all\ncurrent APT versions will refuse to download data from them by default\nin update operations and even if forced to download front-ends like\napt-get(8) will require explicit confirmation if an installation\nrequest includes a package from such an unauthenticated archive.\n\nYou can force all APT clients to raise only warnings by setting the\nconfiguration option Acquire::AllowInsecureRepositories to true.\nIndividual repositories can also be allowed to be insecure via the\nsources.list(5) option allow-insecure=yes. Note that insecure\nrepositories are strongly discouraged and all options to force apt to\ncontinue supporting them will eventually be removed. Users also have\nthe Trusted option available to disable even the warnings, but be sure\nto understand the implications as detailed in sources.list(5).\n\nA repository which previously was authenticated but would loose this\nstate in an update operation raises an error in all APT clients\nirrespective of the option to allow or forbid usage of insecure\nrepositories. The error can be overcome by additionally setting\nAcquire::AllowDowngradeToInsecureRepositories to true or for Individual\nrepositories with the sources.list(5) option\nallow-downgrade-to-insecure=yes.\n",
            "subsections": []
        },
        "SIGNED REPOSITORIES": {
            "content": "The chain of trust from an APT archive to the end user is made up of\nseveral steps.  apt-secure is the last step in this chain; trusting an\narchive does not mean that you trust its packages not to contain\nmalicious code, but means that you trust the archive maintainer. It's\nthe archive maintainer's responsibility to ensure that the archive's\nintegrity is preserved.\n\napt-secure does not review signatures at a package level. If you\nrequire tools to do this you should look at debsig-verify and debsign\n(provided in the debsig-verify and devscripts packages respectively).\n\nThe chain of trust in Debian starts (e.g.) when a maintainer uploads a\nnew package or a new version of a package to the Debian archive. In\norder to become effective, this upload needs to be signed by a key\ncontained in one of the Debian package maintainer keyrings (available\nin the debian-keyring package). Maintainers' keys are signed by other\nmaintainers following pre-established procedures to ensure the identity\nof the key holder. Similar procedures exist in all Debian-based\ndistributions.\n\nOnce the uploaded package is verified and included in the archive, the\nmaintainer signature is stripped off, and checksums of the package are\ncomputed and put in the Packages file. The checksums of all of the\nPackages files are then computed and put into the Release file. The\nRelease file is then signed by the archive key for this Ubuntu release,\nand distributed alongside the packages and the Packages files on Ubuntu\nmirrors. The keys are in the Ubuntu archive keyring available in the\nubuntu-keyring package.\n\nEnd users can check the signature of the Release file, extract a\nchecksum of a package from it and compare it with the checksum of the\npackage they downloaded by hand - or rely on APT doing this\nautomatically.\n\nNotice that this is distinct from checking signatures on a per package\nbasis. It is designed to prevent two possible attacks:\n\no   Network \"man in the middle\" attacks. Without signature checking,\nmalicious agents can introduce themselves into the package download\nprocess and provide malicious software either by controlling a\nnetwork element (router, switch, etc.) or by redirecting traffic to\na rogue server (through ARP or DNS spoofing attacks).\n\no   Mirror network compromise. Without signature checking, a malicious\nagent can compromise a mirror host and modify the files in it to\npropagate malicious software to all users downloading packages from\nthat host.\n\nHowever, it does not defend against a compromise of the master server\nitself (which signs the packages) or against a compromise of the key\nused to sign the Release files. In any case, this mechanism can\ncomplement a per-package signature.\n",
            "subsections": []
        },
        "INFORMATION CHANGES": {
            "content": "A Release file contains beside the checksums for the files in the\nrepository also general information about the repository like the\norigin, codename or version number of the release.\n\nThis information is shown in various places so a repository owner\nshould always ensure correctness. Further more user configuration like\naptpreferences(5) can depend and make use of this information. Since\nversion 1.5 the user must therefore explicitly confirm changes to\nsignal that the user is sufficiently prepared e.g. for the new major\nrelease of the distribution shipped in the repository (as e.g.\nindicated by the codename).\n",
            "subsections": []
        },
        "USER CONFIGURATION": {
            "content": "apt-key is the program that manages the list of keys used by APT to\ntrust repositories. It can be used to add or remove keys as well as\nlist the trusted keys. Limiting which key(s) are able to sign which\narchive is possible via the Signed-By in sources.list(5).\n\nNote that a default installation already contains all keys to securely\nacquire packages from the default repositories, so fiddling with\napt-key is only needed if third-party repositories are added.\n\nIn order to add a new key you need to first download it (you should\nmake sure you are using a trusted communication channel when retrieving\nit), add it with apt-key and then run apt-get update so that apt can\ndownload and verify the InRelease or Release.gpg files from the\narchives you have configured.\n",
            "subsections": []
        },
        "REPOSITORY CONFIGURATION": {
            "content": "If you want to provide archive signatures in an archive under your\nmaintenance you have to:\n\no   Create a toplevel Release file, if it does not exist already. You\ncan do this by running apt-ftparchive release (provided in\napt-utils).\n\no   Sign it. You can do this by running gpg --clearsign -o InRelease\nRelease and gpg -abs -o Release.gpg Release.\n\no   Publish the key fingerprint, so that your users will know what key\nthey need to import in order to authenticate the files in the\narchive. It is best to ship your key in its own keyring package\nlike Ubuntu does with ubuntu-keyring to be able to distribute\nupdates and key transitions automatically later.\n\no   Provide instructions on how to add your archive and key. If your\nusers can't acquire your key securely the chain of trust described\nabove is broken. How you can help users add your key depends on\nyour archive and target audience ranging from having your keyring\npackage included in another archive users already have configured\n(like the default repositories of their distribution) to leveraging\nthe web of trust.\n\nWhenever the contents of the archive change (new packages are added or\nremoved) the archive maintainer has to follow the first two steps\noutlined above.\n",
            "subsections": []
        },
        "SEE ALSO": {
            "content": "apt.conf(5), apt-get(8), sources.list(5), apt-key(8), apt-\nftparchive(1), debsign(1), debsig-verify(1), gpg(1)\n\nFor more background information you might want to review the Debian\nSecurity Infrastructure[1] chapter of the Securing Debian Manual (also\navailable in the harden-doc package) and the Strong Distribution\nHOWTO[2] by V. Alex Brennen.\n",
            "subsections": []
        },
        "BUGS": {
            "content": "APT bug page[3]. If you wish to report a bug in APT, please see\n/usr/share/doc/debian/bug-reporting.txt or the reportbug(1) command.\n",
            "subsections": []
        },
        "AUTHOR": {
            "content": "APT was written by the APT team <apt@packages.debian.org>.\n",
            "subsections": []
        },
        "MANPAGE AUTHORS": {
            "content": "This man-page is based on the work of Javier Fernandez-Sanguino Pena,\nIsaac Jones, Colin Walters, Florian Weimer and Michael Vogt.\n",
            "subsections": []
        },
        "AUTHORS": {
            "content": "Jason Gunthorpe\n\nAPT team\n",
            "subsections": []
        },
        "NOTES": {
            "content": "1. Debian Security Infrastructure\nhttps://www.debian.org/doc/manuals/securing-debian-howto/ch7\n\n2. Strong Distribution HOWTO\nhttp://www.cryptnet.net/fdp/crypto/strongdistro.html\n\n3. APT bug page\nhttp://bugs.debian.org/src:apt\n\nAPT 2.4.14                      06 August 2016                   APT-SECURE(8)",
            "subsections": []
        }
    },
    "summary": "apt-secure - Archive authentication support for APT",
    "flags": [],
    "examples": [],
    "see_also": [
        {
            "name": "apt.conf",
            "section": "5",
            "url": "https://www.chedong.com/phpMan.php/man/apt.conf/5/json"
        },
        {
            "name": "apt-get",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/apt-get/8/json"
        },
        {
            "name": "sources.list",
            "section": "5",
            "url": "https://www.chedong.com/phpMan.php/man/sources.list/5/json"
        },
        {
            "name": "apt-key",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/apt-key/8/json"
        },
        {
            "name": "ftparchive",
            "section": "1",
            "url": "https://www.chedong.com/phpMan.php/man/ftparchive/1/json"
        },
        {
            "name": "debsign",
            "section": "1",
            "url": "https://www.chedong.com/phpMan.php/man/debsign/1/json"
        },
        {
            "name": "debsig-verify",
            "section": "1",
            "url": "https://www.chedong.com/phpMan.php/man/debsig-verify/1/json"
        },
        {
            "name": "gpg",
            "section": "1",
            "url": "https://www.chedong.com/phpMan.php/man/gpg/1/json"
        }
    ]
}