Re: Call for tests: pkg_install-renovation

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

On Wed, Jun 11, 2008 at 02:40:40PM +0100, Alistair Crooks wrote:
> > Use of digital signatures in pkg_install
> > ----------------------------------------
> > 
> > (1) pkg_vulnerabilities: list of known vulnerabilities, provided by
> >     the pkgsrc security team and updated regulary
> > (2) binary packages: check who provided binary packages
> 
> (3) verify that the package has not been modified in any way

The first two points where meant to be formulated out more. There is one
important related topic here I will bring up separate.

> > For (1) gpg is currently the only choice. After pkgsrcCon (?) a PKCS7 
> > signature will be added as well. With the pkg_install-renovation branch,
> > PKCS7 is the only supported verification mechanism for (2) and preferred
> > for (1) once the infrastructure exists.
> 
> This needs to be discussed more fully, timelines (even relatively obscure
> ones like the above) need to be omitted for documents which may live a
> while, etc.

The idea is that once the PKCS7 signature is provided for
pkg-vulnerabilities, GPG is deprecated. We can just provide it for the
sake of the old audit-packages and remove the above paragraph
completely.

> Again, we need to expand this:
[snip]

With the exception of the pkgsrc-security certificate, I would like to
leave the other questions out for now. The possible policies vary a lot
between "I run my own bulk builds for use on other machines" over "I run
bulk builds for $RANDOM_OS" to "I provide the official binary packages
for NetBSD/$ARCH". There should be a sane policy for most or all of this
questions, but we don't have a single answer at the moment, so I would
prefer if we don't give one right now.

> > How to create your own keys:
> > - find the CA.sh script shipped with OpenSSL
> > (/usr/share/examples/openssl on NetBSD)
> > - run CA.sh -newca to create the root certificate, the meta data is only
> > for human beings, so feel free to provide sensible input
> > - in demoCA/newcerts/00.pem is the public key, you can use that as trust
> > anchor
> > - create a subkey using CA.sh -newreq, followed by CA.sh -sign. This
> > creates newcert.pem (public key) and newkey.pem (private key), those
> > will be given to pkg_admin sign-package as arguments
> 
> The notion of a "sub-key" needs to be explained. Possibly public key as well,
> since up to now, all the talk has been about certificates.
>  
> > The location of demoCA might change depending on your openssl.cnf
> > (typically in /etc/openssl).
> > 
> > If not sure about the process, read one of the many, many documents on
> > the internet. The above is the bare essential.
> 
> Well, if we can't document this ourselves, it doesn't deserve to be
> there. We need to document the process that a user needs to go through
> to verify binary packages. References to other documents are good,
> but we need to document the process ourselves fully.

The bare essential is refering to how to setup a basic CA. I don't think
we *should* discuss every impossible implications of this topic, simply
because it doesn't add any value. The target of the description is a
minimal CA for the purpose of providing binary packages for local
consumption or similiar uses. If you want to setup a full scale CA,
other places ar ebetter introductions.

I'm looking for help partially to make clear what this document is
intended to provide and what *not*.

Joerg