On Thu, 2003-08-21 at 10:16, Matt Zimmerman wrote: > Why should it be necessary to modify sources.list to specify the vendor? I > would have either expected this to be determined from the Release file, or > to have a list of trusted vendors and not care which source corresponds to > which vendor.
Well, first because you need to have some way to specify whether or not the source is secured. You can't take the absence of the Release file to mean it's not, for obvious reasons. And a lot of personal-type apt sources aren't secured, and aren't likely to be anytime soon. Secondly, because you don't want someone to be able to replace one valid archive with another, such as replacing Debian stable (and presumably no security holes) with Debian unstable (and presumably some nonempty set of holes). > It would be nice if we could do this without changing the > syntax of sources.list, so that older apts are forward compatible. Well, older apts are forwards compatible - they at least don't barf on the [...] because it's been parsed by sourcelist.cc (and ignored) since before woody. > > I'd also like to try merging the documentation we have into the apt docs > > at some point. > > That would be great; feel free to send me whatever you have. Attached is a copy of the Docbook XML we were using for the website.
<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd";[ <!ENTITY aptSecure "<application>APT Secure</application>"> ]> <article> <articleinfo> <title>APT Secure</title> <author> <firstname>Isaac</firstname> <surname>Jones</surname> <affiliation> <address>[EMAIL PROTECTED]</address> </affiliation> </author> <author> <firstname>Colin</firstname> <surname>Walters</surname> <affiliation> <address>[EMAIL PROTECTED]</address> </affiliation> </author> </articleinfo> <sect1><title>Introduction</title> <para>&aptSecure is the working name of a project to add to <ulink url="http://packages.debian.org/apt";>APT</ulink> the ability to verify the authenticity of Debian packages.</para> <para>The current version of APT and its surrounding infrastructure contain a chain of trust which is never verified by the installing machine. &aptSecure; fixes that problem.</para> </sect1> <sect1><title>Status</title> <para>This project seems to work for simple cases, and we are providing you with code to try it out. We'd like the community to give us feedback about how it works and to help test and debug it. There are certain cases which make this pre-alpha version unhappy, but we expect it to work for most people. If it doesn't work for you, please verify that you are, in fact, a person, and if so, contact the authors (see below) to tell us the problem.</para> <para>The cases where it is known to work are for the canonical Debian <literal>sid</literal> and <literal>woody</literal> entries for <filename>/etc/apt/sources.list</filename>. It is known <emphasis>not</emphasis> to work currently for two-part URIs, the <literal>experimental</literal> distribution, nor <literal>non-US</literal> or the woody security updates.</para> <para>Hopefully, this code will be integrated into the APT CVS repository soon.</para> <para>This document assumes that you have some familiarity with gpg and encryption and stuff like that. If you don't, then you probably shouldn't bother with this pre-alpha program, or you should read up a little bit before bothering with it, or most importantly, before bothering us ;)</para> <para>Also, we should warn you that there are still some policy decisions to be made. Correctness of policy is, of course, at least as important as correctness of code. Some of the stuff below might change.</para> </sect1> <sect1><title>The Chain of Trust</title> <para>The chain starts with the maintainer who signs and uploads her packages. That signature is checked against the key that she uploaded when she became an official Debian developer, which was itself verified personally by other Debian developers.</para> <para>Once the uploaded package is verified as having been signed by the maintainer, 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 <ulink url="http">archive key</ulink> which is created once a year and distributed by the FTP server. This key is also on the Debian keyring.</para> <para>In theory, therefore, the end user, having added the archive key to his keyring, can check that the <filename>Release</filename> file was signed by the proper key, can check the MD5 sums of all the <filename>Packages</filename> files, and can check the MD5 sums of all the Debian packages. The current version of APT does in fact check the MD5 sums of the Debian packages against those in the <filename>Packages</filename> file, but it goes no further up the chain of trust.</para> <para>In theory, this makes APT vulnerable to a variety of attacks. Suffice it to say that if a malicious person can alter any packages, then they can gain full access to the installing machine.</para> </sect1> <sect1><title>Where APT Secure Comes In</title> <para>&aptSecure; is an alteration to APT to complete this chain of trust. With it, you can add a set of keys that you trust to your keyring, and alter your <filename>/etc/apt/sources.list</filename> file accordingly. Then when you run a command like <userinput>apt-get update</userinput>, APT will walk back along the chain of trust for you, and freak out if something looks suspicious. (You, in turn will freak out, and do your best to freak out the next link in the chain.)</para> </sect1> <sect1><title>How it Works</title> <para>Step zero is, of course, to install &aptSecure; (see below).</para> <para>We'll assume that you're using Debian's official packages (and therefore Debian's official archive key), though a similar method will work for other sources that APT might use.</para> <para>First, you should get Debian's <ulink url="http://ftp-master.debian.org/";>archive key</ulink>. Import this key into a keyring at <filename>/etc/apt/trusted.gpg</filename>. So for instance:</para> <screen> $ wget http://ftp-master.debian.org/ziyi_key_2003.asc $ gpg --no-default-keyring --keyring=/etc/apt/trusted.gpg --import ziyi_key_2003.asc </screen> <para>Now you need a way to associate your newly imported key with the source that you download your packages from. This is accomplished with the help of a new file, vendors.list<footnote><para>See <userinput>man vendors.list</userinput> for more information.</para></footnote>. In this file, you will be able to put the fingerprint of any keys that you will be using to verify the <filename>Release</filename> files. For instance, in <filename>/etc/apt/vendors.list</filename>, you might have:</para> <programlisting> simple-key "debian" { Fingerprint "EB2FA2AF170D235926A77BF3B629A24C38C6029A"; Name "Debian Archive Automatic Signing Key (2003) <[EMAIL PROTECTED]>"; } </programlisting> <para>The <literal>debian</literal> bit after <literal>simple-key</literal> is like a nickname for the key, we'll use this later. You can get the fingerprint for the newly imported key using a command like this:</para> <screen> $ gpg --no-default-keyring --keyring=/etc/apt/trusted.gpg --fingerprint [EMAIL PROTECTED] </screen> <para>But get rid of the whitespace in the "Key fingerprint" output.</para> <para>Now that you've created your <filename>vendors.list</filename> file, you can associate this key with a particular apt source. Open up your <filename>/etc/apt/sources.list</filename> file and change lines that look like this:</para> <programlisting> deb http://ftp.debian.org/debian sid main </programlisting> <para>to instead look like this:</para> <programlisting> deb [debian] http://ftp.debian.org/debian sid main </programlisting> <para>That <literal>[debian]</literal> part maps to the key nickname that we mentioned above. This source (<literal>ftp.debian.org</literal>) will now be authenticated with APT Secure, to your unending joy. Sources which aren't prefixed by a key identifier will not be authenticated. So if you do not change your <filename>sources.list</filename> file, then Secure APT should behave pretty much like APT.</para> <para>Did I mention that you have to install &aptSecure;?</para> </sect1> <sect1><title>Installation</title> <para>Patched Debian <literal>apt</literal> packages can be acquired by adding the following to your <filename>/etc/apt/sources.list</filename>:</para> <programlisting> deb http://monk.debian.net/debian/ unstable/ </programlisting> <para>Or if you're running woody:</para> <programlisting> deb http://monk.debian.net/debian/ woody/ </programlisting> <para> Since this will replace your current <literal>apt</literal> packages, you may want to keep the older packages around. </para> <para> If you're just interested in the patches, you can download them <ulink url="http://monk.debian.net/apt-secure/patches/";>here</ulink>. </para> </sect1> <sect1><title>What does this mean for people who distribute packages?</title> <para>This will require no change for Debian maintainers. They've already done their bit by getting their keys into Debian's keyring.</para> <para>For now, even those who want to create their own apt sources don't have to change anything until you want your sources to be authenticated, in which case you'll have to generate and sign Release files, and find a secure way to distribute your key. Someday, APT might force all sources to be verified, but those kinds of policy decisions have not yet been made.</para> </sect1> <sect1><title>Authors</title> <para>This code is a smallish change to a largeish program, so of course the original authors deserve credit. Also, a similar thing has been implemented by Connectiva in their fork of APT, and we used a small amount of their code.</para> <para>Having said that, the current version of &aptSecure; was implemented by <ulink url="mailto:[EMAIL PROTECTED]">Colin Walters</ulink> and <ulink url="mailto:[EMAIL PROTECTED]">Isaac Jones</ulink>.</para> </sect1> </article>
