Matt Zimmerman <[EMAIL PROTECTED]> writes: [...] >> I'd be happy to write some text for the user's guide if you like? > > That would be excellent indeed! Here is an outline for how the existing > code works:
OK I'm looking at file:///usr/share/doc/apt-doc/guide.html/index.html. What do you think of this plan of attack: - A couple of comments in the "apt-get" section about what happens during update and install/upgrade/dist-upgrade like what you wrote below. - A section on apt-key - And / or a section (section 4 pushing "interface" to 5?) called "Signature Checking" which might have some section similar to the current apt-secure web page (http://monk.debian.net/apt-secure/index.html) - The Chain of Trust - Some of the stuff from "How it works" and - Some stuff from "What does it mean for people who distribute packages", though perhaps this doesn't fit in. This document doesn't talk much about sources (but that doesn't mean that it shouldn't, right?) - Pointers to the apt-get section and man pages for more info > apt-get update: > > 1. Release.gpg and Release are downloaded if present. If either is missing, > both are ignored. So it becomes an unauthenticated source and it will warn you and offer to abort when you install later (as below)? > 2. The signature in Release.gpg is verified against Release and checked > against the keyring. If verification fails, Release is ignored. Likewise. > 3. Packages and Sources are downloaded as normal. If Release was present > and verified, the sums are checked. The current code becomes paranoid at > this point, and if anything goes wrong, it errors out, rather than falling > back. So, having a broken, correctly signed Release file is a fatal error, > while a missing or unsigned Release file is no error at all. When "it errors out" (due to gpgv failing), the Release file will be left in place, but the Packages file will either not be put into place, or it will be deleted? > apt-get install/upgrade/dist-upgrade: > > 1. Packages are queued for download as normal, keeping track of whether they > came from an authenticated source or not So apt now sandboxes things based on origin, correct? This solves the issue that came up on the BTS in September? > [...] >> So vendors.list is gone, right? If I recall, you had decided to get >> rid of this and include the code anyway? > > Right, the code for vendors.list is mostly still present, but unused. > [...] Just FYI, I noticed that I got a parse error with the old sources.list syntax: deb [keyID] ... We didn't add that to apt, it was already there in some released versions, and would be parsed and ignored. It probably doesn't matter but I thought I'd let you know. peace, isaac
