Re: apt sigcheck patches
On Mon, Dec 29, 2003 at 08:05:39PM -0500, Isaac Jones wrote:
> 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
This seems fine.
> > 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)?
Correct.
> > 2. The signature in Release.gpg is verified against Release and checked
> > against the keyring. If verification fails, Release is ignored.
>
> Likewise.
Yes.
> > 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?
What I meant was, if gpgv fails, this is OK, and we fall back to treating it
as an unauthenticated source. However, if gpgv succeeds, then any problems
with the contents of Release (such as an md5sum mismatch with Packages or
Sources) are treated as fatal and the {Packages,Sources} index will not be
used at all. This is mostly because it was simpler based on how the code is
structured.
> > 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?
What it does is to examine all of the indexes where the package/version
could be obtained from, and do a logical AND on their authenticated status.
So if any of them are unauthenticated, it will raise a red flag.
> 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.
Hmm; it looks like I did comment out that bit in sourcelist.cc. Do you
think it is important to support it?
--
- mdz
Reply to: