Re: apt sigcheck patches
Matt Zimmerman <mdz@debian.org> 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
Reply to: