Re: apt sigcheck patches
On Mon, Dec 29, 2003 at 09:51:49PM -0500, Isaac Jones wrote:
> 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?
Yes, perhaps the howto would be more appropriate. Perhaps it should even be
moved or copied into the apt tree.
> > 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?
They are not put into place. They're currently left around in partial
because I figured it would make it easier to diagnose early problems. I
think there may be a couple of cases which need to be fixed where it might
be possible for an old .gpg file to be left in place if List-Cleanup is
disabled, and those need to be addressed before this is ready for
prime-time.
> Likewise, what happens to the Packages file if the MD5 sum of the Packages
> file does not match the Release file?
It is renamed to <filename>.FAILED and left in partial. As above, I think
the old one may stay in place if List-Cleanup is false.
> 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.
That's essentially the approach I have taken as well. The files are not
moved out of partial/ until they are authenticated.
> > 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.
Should be fixed in CVS now.
> BTW, it would probably be good to update the vendors.list man page to
> indicate that it's not really used.
I think it makes more sense to just exclude it from the .deb for now. I'll
do that.
--
- mdz
Reply to: