Re: Merge of pkg_install-renovation

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Wed, Nov 05, 2008 at 02:35:56AM +0000, Alistair Crooks wrote:
> Yes, these are both true (the local packages thing is stretching it a
> bit, it's only binary package grabbing that you're talking about, but
> whatever), but they are still regressions.

I was told one use case is NFS shared package directory. If it is a
local filesystem, gpg can be used to verify them first without trouble.
The problem with the NFS case is the above mentioned TOCTOA -- the
package can very well be replaced in the meantime.

> I'd like to see the previous support for gpg (and pgp) restored before
> this is merged. And, yes, I'm doing my best to get the second one done
> from a library, but it will have to be done to my own timescales, and it
> may not be done tomorrow. But having gpg signatures is important to me,
> and I see no reason for a regression here.

The problem is that the detached signatures is exactly that -- they break
the abstraction of "here is an archive, deal with it". The other problem
is that the GPG signature doesn't tell you *what* was signed. Let's
consider the far-fetched assumption that we have a binary package with a
security issue e.g. on ftp.netbsd.org for the desired architecture.
Nothing stops the attacker from renaming that and getting pkg_add e.g.
to pull it up as dependency.

This leads to the real question -- was is needed here? Integration with
a GPG web-of-trust? For that a better approach is to include a GPG
signature of the index file next to the X509 signature and validate
that. This allows both verifying that the file we want to install is the
one we asked for and it allows transparent operation independent of the
source of the package.

Joerg