[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Request for Review: APT manpages



On Tue, May 29, 2012 at 10:37 AM, Justin B Rye <jbr@edlug.org.uk> wrote:
>>    <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.

Just for the sound of it, i like "several" more, too.

With the "chain" we probably get away as a supply chain in the military
isn't necessarily made up of identical links either, and we establish here
a supply chain of packages and just try to make it trust-able.


>>    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?)

Yeap, they are really nothing special and therefore i am kinda worried to
add InRelease everywhere - also because we don't mention Release.gpg
even through it is what signs the Release file, so in the end InRelease is
more a Release.gpg which includes also Release file content…

The paragraph above worries me for other reasons: "created once a year" and
"distributed through the FTP server". Keys are created on demand now and
"… though _the_ FTP…" - what is this supposed to mean? Do we only have
one server distribution the file and is it only available through ftp?
Beside that i don't know what "this key is also on the Debian keyring" means,
given that it is in the Debian archive keyring.

So how about these two paragraphs instead:

   <para>
   Once the uploaded package is verified and included in the archive,
   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 Debian release
   and distributed alongside the packages and the Packages files on
   Debian mirrors. The keys are in the Debian archive keyring available in
   the <package>debian-archive-keyring</package> package.
   </para>

>>    <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>

   <para>
   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.
   </para>

(I am not particularly happy with the end of the sentence,
 but i don't really know why)


>>    <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!)

(I will never understand why it says "man" and the usual attacker is
 a girl named Mallory…)


Best regards

David Kalnischkies


Reply to: