Re: officially signed packages

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Sun, Apr 06, 2014 at 06:37:36PM +0200, Pierre Pronchery wrote:
> I'd say one important thing is the ability to verify package
> signatures without relying on any package to be installed already. I
> think that's possible for X509-based signatures. In the case of GPG
> signatures though, installing security/gnupg is currently required -
> and it obviously can't verify itself while installing.

That's what security/netpgpverify is meant for - it has zero pre-req
packages. As a bonus, it also verifies ssh key signatures.

As far as X.509 signatures go, the problem is not the signatures
themselves, it's how the trust is conveyed to go with the key.  I've
yet to sign someone's X.509 key.  In fact I've yet to have someone
sign my X.509 key.  This is mainly because I don't have one.  I have
numerous signatures on my pgp keys, though, and internally, my ssh pub
key is available on any machine I log in to.
 
> Checking GPG signatures could however be done with netpgp(1) from
> base. It doesn't work out of the box yet, but it shouldn't be much
> work to achieve (?). Feel free to beat me to it in any case :)

It certainly doesn't have the same command line arguments that gpg
has, but this is ABSOLUTELY by design.
 
> Once this done I feel like it should be possible to let official
> NetBSD releases default to signed binary packages, shipping the
> release with the GPG public key pre-installed (possibly in a distinct
> keyring), and then strictly checking the signatures by default. This
> may be problematic on slow architectures though, this will require
> testing on the slower models of each to ensure operations on packages
> are still usable - when installing in particular.

This is the main stumbling block, and I'm a bit disappointed that
it hasn't been addressed before now.

You need buy-in from whoever is building the packages for them to sign
them.  Bulk signature of packages on the build host, with a trusted
high-value key, is not something I want to consider.  So either a
separate key should be created simply for signing, or some form of
ephemeral key signing and verification (check out
othersrc/external/bsd/starsign) is necessary, where the key is
automatically generated, but the trust is given by a high value
signature on the ephemeral key.
 
> On a related note, the file format for signed packages isn't
> particularly great at the moment. It will probably make sense to
> re-design it at some point, but to me this is not a blocker.

Agreed, but it's of lesser importance.

Best,
Alistair