Re: Merge of pkg_install-renovation

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

On Sun, Nov 09, 2008 at 01:32:14PM +0000, Alistair Crooks wrote:
> The reason we need to keep the old code around for gpg signing until
> the library based gpg verification is available is because the X.509
> signatures onlt go some way to providing a solution.

Let me repeat my question: What exactly do you need for GPG?
Do you need GPG detached signature validation? Do you need to employ
GPG's web of trust? I think the former is not very useful as it is
limited in use and where it can be used savely, just calling GPG first
provides the same level of functionality.

For the later, that is a valid use case. To recap, a X509 signed binary
package is a tarball with
- a description of the package (size, package name, block hashes)
- a X509 signature of that block
- the binary package

If you want to replace the X509 signature, it could be as simple as
replacing the second file in the tarball (or adding another one for that
matter), which does the same with GPG.

The advantage of that scheme over plain signatures is that you can detect
mismatches between signed package and file name, you don't need to do a
two pass validation over the whole file (things like Qt4 can be large)
and it means that code that deals with binary packages has a single file
to process and can easily abstract the various cases (no signature,
x509-only, gpg-only, x509+gpg).

The downside is of course that verifying the signature is more involved
than just calling gpg --verify.

Joerg