<?xml version="1.0" encoding="utf-8" standalone="no"?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
-
-<!ENTITY % aptent SYSTEM "apt.ent">
-%aptent;
-
-<!ENTITY % aptverbatiment SYSTEM "apt-verbatim.ent">
-%aptverbatiment;
-
+<!ENTITY % aptent SYSTEM "apt.ent"> %aptent;
+<!ENTITY % aptverbatiment SYSTEM "apt-verbatim.ent"> %aptverbatiment;
+<!ENTITY % aptvendor SYSTEM "apt-vendor.ent"> %aptvendor;
]>
<refentry>
&apt-email;
&apt-product;
<!-- The last update date -->
- <date>2012-05-21T00:00:00Z</date>
+ <date>2016-07-07T00:00:00Z</date>
</refentryinfo>
<refmeta>
by apt to authenticate packages. Packages which have been
authenticated using these keys will be considered trusted.
</para>
+ <para>
+ Note that if usage of <command>apt-key</command> is desired the additional
+ installation of the GNU Privacy Guard suite (packaged in
+ <package>gnupg</package>) is required. For this reason alone the programmatic
+ usage (especially in package maintainerscripts!) is strongly discouraged.
+ Further more the output format of all commands is undefined and can and does
+ change whenever the underlying commands change. <command>apt-key</command> will
+ try to detect such usage and generates warnings on stderr in these cases.
+ </para>
</refsect1>
<refsect1><title>Commands</title>
&synopsis-param-filename; or if the filename is <literal>-</literal>
from standard input.
</para>
-
+ <para>
+ It is critical that keys added manually via <command>apt-key</command> are
+ verified to belong to the owner of the repositories they claim to be for
+ otherwise the &apt-secure; infrastructure is completely undermined.
+ </para>
+ <para>
+ Instead of using this command a keyring can be placed directly in the
+ <filename>/etc/apt/trusted.gpg.d/</filename> directory with a descriptive name
+ (same rules for filename apply as for &apt-conf; files) and "<literal>gpg</literal>"
+ as file extension.
+ </para>
</listitem>
</varlistentry>
</listitem>
</varlistentry>
- <varlistentry><term><option>list</option></term>
+ <varlistentry><term><option>list</option>, <option>finger</option></term>
<listitem>
<para>
- List trusted keys.
+ List trusted keys with fingerprints.
</para>
</listitem>
</varlistentry>
-
- <varlistentry><term><option>finger</option></term>
- <listitem>
- <para>
-
- List fingerprints of trusted keys.
-
- </para>
- </listitem>
- </varlistentry>
-
<varlistentry><term><option>adv</option></term>
<listitem>
<para>
-
- Pass advanced options to gpg. With adv --recv-key you can download the
- public key.
-
+ Pass advanced options to gpg. With <command>adv --recv-key</command> you
+ can e.g. download key from keyservers directly into the the trusted set of
+ keys. Note that there are <emphasis>no</emphasis> checks performed, so it is
+ easy to completely undermine the &apt-secure; infrastructure if used without
+ care.
</para>
</listitem>
</varlistentry>
- <varlistentry><term><option>update</option></term>
+ <varlistentry><term><option>update</option> (deprecated)</term>
<listitem>
<para>
-
Update the local keyring with the archive keyring and remove from
the local keyring the archive keys which are no longer valid.
The archive keyring is shipped in the <literal>archive-keyring</literal> package of your
- distribution, e.g. the <literal>debian-archive-keyring</literal> package in Debian.
-
+ distribution, e.g. the &keyring-package; package in &keyring-distro;.
+ </para>
+ <para>
+ Note that a distribution does not need to and in fact should not use
+ this command any longer and instead ship keyring files in the
+ <filename>/etc/apt/trusted.gpg</filename> directory directly as this
+ avoids a dependency on <package>gnupg</package> and it is easier to manage
+ keys by simply adding and removing files for maintainers and users alike.
</para>
-
</listitem>
</varlistentry>
<listitem>
<para>
- Work similar to the <command>update</command> command above, but get the
- archive keyring from an URI instead and validate it against a master key.
+ Perform an update working similarly to the <command>update</command> command above,
+ but get the archive keyring from a URI instead and validate it against a master key.
This requires an installed &wget; and an APT build configured to have
a server to fetch from and a master keyring to validate.
- APT in Debian does not support this command and relies on
+ APT in Debian does not support this command, relying on
<command>update</command> instead, but Ubuntu's APT does.
</para>
<para>Note that options need to be defined before the commands described in the previous section.</para>
<variablelist>
<varlistentry><term><option>--keyring</option> <option>&synopsis-param-filename;</option></term>
- <listitem><para>With this option it is possible to specify a specific keyring
+ <listitem><para>With this option it is possible to specify a particular keyring
file the command should operate on. The default is that a command is executed
on the <filename>trusted.gpg</filename> file as well as on all parts in the
<filename>trusted.gpg.d</filename> directory, though <filename>trusted.gpg</filename>
&file-trustedgpg;
- <varlistentry><term><filename>/etc/apt/trustdb.gpg</filename></term>
- <listitem><para>Local trust database of archive keys.</para></listitem>
- </varlistentry>
-
- <varlistentry><term><filename>/usr/share/keyrings/debian-archive-keyring.gpg</filename></term>
- <listitem><para>Keyring of Debian archive trusted keys.</para></listitem>
- </varlistentry>
-
- <varlistentry><term><filename>/usr/share/keyrings/debian-archive-removed-keys.gpg</filename></term>
- <listitem><para>Keyring of Debian archive removed trusted keys.</para></listitem>
- </varlistentry>
-
</variablelist>
</refsect1>
projects / apt.git / blobdiff