apt-secure.8.xml turns out to be fairly simple too. I mean, I change
a lot of lines, but it's mostly trivial comma-juggling.
> <refsect1><title>Description</title>
> <para>
> Starting with version 0.6, <command>apt</command> contains code
[...]
(Cobwebby but still true, unless we also need to explain InRelease
files)
> <para>
> If a package comes from a archive without a signature or with a
an ,
> signature that apt does not have a key for that package is
,
> considered untrusted and installing it will result in a big
,
> warning. <command>apt-get</command> will currently only warn
> for unsigned archives, future releases might force all sources
;
> to be verified before downloading packages from them.
> </para>
>
> <para>
> The package frontends &apt-get;, &aptitude; and &synaptic; support this new
> authentication feature.
> </para>
> </refsect1>
>
> <refsect1><title>Trusted archives</title>
>
> <para>
> The chain of trust from an apt archive to the end user is made up of
> different steps. <command>apt-secure</command> is the last step in
I'd suggest saying "several" steps. The point is that it isn't a
single step, not that they're non-identical. Of course, chains are
more traditionally made up of (identical!) links rather than steps,
but never mind.
> this chain, trusting an archive does not mean that the packages
;
> that you trust it do not contain malicious code but means that you
I *think* that's trying to say something along the lines of "does not
mean that you trust its packages not to contain malicious code".
> trust the archive maintainer. It's the archive maintainer
's
> responsibility to ensure that the archive integrity is correct.
's preserved.
[...]
> 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
Move "in order to become effective" to sentence-initial position.
> a maintainer within the Debian maintainer's keyring (available in
X
"Within" doesn't quite work... it would be simpler if I'm allowed to
drop the redundant reference to the key being "of a maintainer":
In order to become effective this upload needs to be signed by a key
contained in the Debian Maintainers keyring (available in
> the debian-keyring package). Maintainer's keys are signed by
Maintainers'
> other maintainers following pre-established procedures to
> ensure the identity of the key holder.
> </para>
>
> <para>
> Once the uploaded package is verified and included in the archive,
> the maintainer signature is stripped off, an MD5 sum of the package
^and
> is computed and put in the Packages file. The MD5 sum of all of the
sums
> packages files are then computed and put into the Release file. The
Packages files
> 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.
> </para>
Should this be updated to explain where InRelease files fit into this?
(They're just inline-signed, is that right?)
> <para>
> Any end user can check the signature of the Release file, extract the MD5
End users can
> 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
they
> downloaded Debian package was checked. Now both the MD5 sum and the
> signature of the Release file are checked.
> </para>
(Cobwebby)
> <para>Notice that this is distinct from checking signatures on a
> per package basis. It is designed to prevent two possible attacks:
> </para>
>
> <itemizedlist>
> <listitem><para><literal>Network "man in the middle"
> attacks</literal>. Without signature checking, a malicious
malicious
> agent can introduce himself in the package download process and
agents themselves into
(You don't need a Y chromosome to be a man in the middle!)
> 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
ARP
> attacks).</para></listitem>
[...]
> <refsect1><title>User configuration</title>
> <para>
> <command>apt-key</command> 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.
Is this saying that (e.g) a Wheezy install gives you the keys for
Wheezy? If so I think I'd replace "provide" with "contain".
[...]
> <para>Whenever the contents of the archive changes (new packages
change
> are added or removed) the archive maintainer has to follow the
> first two steps previously outlined.</para>
outlined above.
[...]
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
--- old/apt-secure.8.xml 2012-05-21 10:41:17.000000000 +0100
+++ new/apt-secure.8.xml 2012-05-28 22:50:52.247392479 +0100
@@ -57,11 +57,11 @@
</para>
<para>
- 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
+ If a package comes from an 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. <command>apt-get</command> will currently only warn
- for unsigned archives, future releases might force all sources
+ for unsigned archives; future releases might force all sources
to be verified before downloading packages from them.
</para>
@@ -75,11 +75,11 @@
<para>
The chain of trust from an apt archive to the end user is made up of
- different steps. <command>apt-secure</command> 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. It's the archive maintainer
- responsibility to ensure that the archive integrity is correct.
+ several steps. <command>apt-secure</command> 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.
</para>
<para>apt-secure does not review signatures at a
@@ -90,28 +90,28 @@
<para>
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
+ 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
+ the debian-keyring package). Maintainers' keys are signed by
other maintainers following pre-established procedures to
ensure the identity of the key holder.
</para>
<para>
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
+ the maintainer signature is stripped off, and an MD5 sum of the package
+ is computed and put in the Packages file. The MD5 sums 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.
</para>
<para>
- 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
+ End users can check the signature of the Release file, extract the MD5
+ sum of a package from it, and compare that with the MD5 sum of the
+ package they 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.
</para>
@@ -122,11 +122,11 @@
<itemizedlist>
<listitem><para><literal>Network "man in the middle"
- attacks</literal>. Without signature checking, a malicious
- agent can introduce himself in the package download process and
+ attacks</literal>. 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).</para></listitem>
<listitem><para><literal>Mirror network compromise</literal>.
@@ -145,8 +145,8 @@
<refsect1><title>User configuration</title>
<para>
<command>apt-key</command> 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
+ of keys used by apt. It can be used to add or remove keys, although
+ an installation of a given release will automatically contain the
default Debian archive signing keys used in the Debian package
repositories.
</para>
@@ -183,7 +183,7 @@
</itemizedlist>
- <para>Whenever the contents of the archive changes (new packages
+ <para>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.</para>
Attachment:
apt-secure.8.xml
Description: XML document