Re: signed packages documentation

[Greg Troxel <gdt%lexort.com@localhost>]

Joerg Sonnenberger <joerg%bec.de@localhost> writes:

> On Thu, Jul 23, 2020 at 11:36:38AM -0400, Greg Troxel wrote:
>>   pkg_create does not say anything about signed packages.  Most of the
>>   following probably should be addressed in pkg_create(1).
>
> pkg_create doesn't deal with signed packages.

Thanks for explaining some of this.

It would be good to say that in the man page then, because it's a
reasonable guess that one could sign a package at creation time.  I
don't mean to say the current design is bad - it's nicer to be able to
split it actually - but it's very hard for someone coming at this fresh
to find their way.

>>   pkg_install.conf mentions "GPG_SIGN_AS" as a config variable.  It
>>   doesn't speak to where the key is, or what program is used to sign.
>>   We have netpgp in NetBSD base, and there is gpg 1 and 2 in pkgsrc.
>
> Read again? There are four paragraphs above that variable...

I see that now.  (The lack of a description of how to do things, rather
than having to invert the description from variables, makes things much
harder to figure out.)

So is netpgp in the picture at all?  Or is it usable as a "GPG" program
(which it isn't, but it looks like it is intended to be
argument-compatible)?

My question was prompted from the lack of clarity in pkg_install.conf,
no hints in pkg_create that signing is in pkg_admin, and and the
apparent conflation (now resolved in my head) of gpg and x509, which led
me to wonder if one had to do format conversion of keys.

>>   Building packages and signing them as an automated process seems to
>>   require a key without a passphrase or gpg-agent.  This isn't explained
>>   at all.  It seems obvious that gpg-agent is preferred to a key without
>>   a passphrase.
>
> Those are two options. The third option is to upload to a second system
> and do the signing on that one, so that the key material is not
> available to the build environment at all.

Good point.

>>   There is some notion of certificate chains, and it is not clear if
>>   there is any provision for including these in a signed package,
>>   similar to have pkix sends a cert chain for TLS.
>
> There are two models for signing supported, using PGP signatures and
> using x509 signatures. Certificate chains are used for the later.

The notion of two PKI models, and validation is not clearly explained
anywhere.  So is it fair that:

  CERTIFICATE_ANCHOR_PKGS
  CERTIFICATE_CHAIN

are (ignoring vulnerability file for now) only used for verifications,
and if set is a declaration that packages must be signed with x509?

I see GPG_KEYRING_VERIFY, but nothing speaks to how keys in the keyring
are processed, in terms of needing to be marked trusted, validatable
from trusted keys following gnupg defaults, just in the keyring, or ?

Is there a technical/operational preference for gpg vs x509 here?

(Not that important, but the behavior if both CERTIFICATE_ANCHOR_PKGS
and GPG_KEYRING_VERIFY are defined is not clear.)

It seems the easiest path is:

  on builder, create a keyring with gpg2 and generate a key

  put that keyring and key id in GPG_KEYRING_SIGN and GPG_SIGN_AS

  set GPG to /usr/pkg/bin/pgp2

  build packages normally

  configure gpg-agent because otherwise you will be asked for the
  passphrase once per package

  write a script to sign all packages puting output into a signed
  package dir, and run it

  zeroize the agent

  in the signed packaged dir, generate a pkg_summary

  distribute

  export pubkey used to sign

  ...

  on verifier, securely/out-of-band get signing pubkey and put it in a keyring

  set GPG to /usr/bin/netpgp on NetBSD,
    or to /usr/pkg/bin/gpg2 which has to be in the binary bootstrap kit

  set GPG_KEYRING_VERIFY to it

  set VERIFIED_INSTALLATION=always