Re: apt sigcheck patches
Matt Zimmerman <mdz@debian.org> writes:
> 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:
(SNIP)
> This seems fine.
I noticed that there's also the apt-howto which seems much more
complete than the User's manual. I'm curious as to why we have both?
Perhaps I should make my changes to the howto?
>> 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.
Out of curiosity, if gpgv finds a bad signature, what happens to the
Release and Release.gpg files? Are they deleted or not put into
place?
Likewise, what happens to the Packages file if the MD5 sum of the
Packages file does not match the Release file?
We were a little worried about cases where the files were downloaded
and apt quits with an error, but then next time apt was run, EVIL
Release or Packages files were already in place and so APT would run
without an error. To prevent this from ever happening, I think we
decided to not move them out of partial and to delete them.
>> 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?
I have the feeling that it was put there because it was a partial
application of the Connectiva code that didn't break anything.
Likewise with the vendors.list parsing, which was there already (and
the man page has been distributed with some versions of apt). If we
expect to someday have to link items from sources.list with items in
vendors.list, I would leave it in. It might also cause some
frustrations for people who used our original patch that required
those be added, since now there will be parse errors. Compatibility
with the Connectiva branch is another reason to leave it in. None of
those are particularly compelling, though.
BTW, it would probably be good to update the vendors.list man page to
indicate that it's not really used.
peace,
isaac
Reply to: