Bug#203741: apt-secure
On Mon, Sep 08, 2003 at 12:02:39AM -0400, Colin Walters wrote:
> First of all, despite what we were saying initially on IRC, if you're
> prompting before the packages are actually downloaded, then there are no
> problems with polluting the cache, no?
The problem situation I was talking about is where someone downloads a
package, then changes their trust policy, then runs an upgrade/install.
Since the package is already downloaded, under the current setup I don't
think they get the warning. Since the user should be able to change their
policy and have it take effect immediately, this should be fixed. I'm
looking into the pkgDepCache changes now.
> The other issue about displaying which sources (in addition to which
> packages) were insecure is probably less pressing.
I am concerned about the potential length of that warning message, if it
includes the source. There is no short, unique identifier for it currently.
If 100 packages are being installed and the source name is displayed, I
think the message would end up being 100 lines long. Since it currently
displays only the package name, it takes advantage of the existing code to
provide a nicely formatted list which is not too large.
The problem situation you're describing, if I understand correctly, is where
the user has an insecure source that they want packages from regularly, and
have another insecure source which they do not want packages from regularly,
and should be able to see at a glance that packages are coming from the
unexpected insecure source rather than the expected one.
If so, I agree that this is minor, as any source being used for regular
regular upgrades should probably be secured.
Which reminds me; we need to whip up some tools to make this easy. How is
this done for the Debian archive? Maybe we can borrow those tools, or use
them for comparison.
> On Sun, 2003-09-07 at 16:10, Matt Zimmerman wrote:
> > Oh, another thing. The error/warning situation could probably use some
> > cleanup. While at this point, someone who installs the new code on an
> > existing setup will continue to have a functional apt (with the addition of
> > the confirmation question), but they will get a bunch of warnings from
> > apt-get update as it tries to verify signatures and finds that it doesn't
> > have a keyring (or maybe even gnupg).
>
> We should have apt Depend: on gnupg, and also ship a default keyring
> with the Debian ftp keys, perhaps with a prompt for whether or not to
> trust the keys.
I'm wary of a Depends: on gnupg, since apt is fully functional without it.
We should definitely ship some keys by default, but if we ship them in the
form of a gnupg keyring, rather than exported keys, I think we can avoid the
dependency and just copy the keyring into place (assuming that gnupg
keyrings are reasonably portable across versions).
> > - It looks like pkgAcqIndexRel isn't used anymore. If this is correct, I
> > think we should remove it.
>
> I think this is still used for semi-obscure pinning purposes. We should
> probably try to merge that back into the main Release file.
In current apt CVS, it is only used in debindexfile.cc to fetch the Release
file. Since the the metaindex stuff does that now, it's obsolete and I
think it should be removed.
One thing that pkgAcqIndexRel does that pkgAcqMetaIndex doesn't do is the
Custom600Headers bit, which I think definitely should be added to
pkgAcqMetaIndex (unless you intentionally wanted it to be fetched every
time).
> > - I'm torn about how to handle the situation where a Release file is
> > signed, but the public key isn't available. On one hand, I don't want
> > to issue a warning all the time, because I think it will be a normal
> > situation.
>
> This doesn't seem like a very normal situation - if you don't trust the
> source, then you don't trust the source, and you should see a warning.
I think the warning during update is superfluous because the user will be
asked for confirmation when installing packages. I might add a source to my
sources.list that I don't generally trust, knowing that apt will ask for
confirmation before installing packages from it. However, I would still get
a warning on every single apt-get update.
--
- mdz
Reply to: