Re: signed packages documentation

[Havard Eidnes <he%NetBSD.org@localhost>]

>> 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)?
>
> It is used for the verification, but couldn't do the signing for some
> reasons that I forgot.

Is that precise?  Is it "is used" or "can be used"?  Or is it "is used
by default" if the GPG variable is not set in pkg_install.conf?

pkg_install.conf(5) says under the description of the GPG variable:

             It can also be used to verify and sign binary packages.

Again, is that precise?  "Can be used"?  What, then, determines if it
*is* used?  Should this not instead be "will be used"?

What program is used to verify signatures if the GPG variable isn't
set in that file?  The man page doesn't say whether there's a default
or not, and I think it should, especially if there *is* a default.

>> The notion of two PKI models, and validation is not clearly explained
>> anywhere.

Right.  Neither x.509 nor PKI is mentioned in pkg_install.conf(5),
only via an oblique hint to "PEM-encoded" certificates.

Similarly, pkg_admin(1) when it says

     gpg-sign-package pkg spkg
             Sign the binary package pkg using GPG and write the result to
             spkg.

could do with an explicit cross reference to the GPG* variables in
pkg_install.conf(5), in addition to the reference to that man page in
the "SEE ALSO" section.

     check-signature file ...
             Reports if file is a correctly signed package.

is also on the overly terse side concerning what influences its
operation and what the administrator must do (if anything) before
signatures can be checked.

> pkg_add opens the package, sees a signature and checks if it can verify
> it. If it can, it considers the package signed, otherwise it continues.
> A package can have a x509 signature, a PGP signature or both or none at
> all. If a signature type is found and there is no corresponding trust
> configured, the signature is rejected/ignored.

A statement about that ought IMHO to go into a suitable part of the
documentation / man pages.

E.g. the pkg_add(1) man page on 9.0 in the "TECHNICAL DETAILS" section
says nothing about handling or checking of signed packages, it most
probably should -- there should probably be a new "item 1" on that
list.  The only place where "sign" is mentioned in that man page is in
the "WARNING" section.

Also, the "DESCRIPTION" says packages are "previously created with the
pkg_create(1)" command -- no mention that pkg_admin(1) can also be
involved in the creation of (signed) packages, which could have been a
hint to us who thought that pkg_create(1) would be able to create
signed packages.

>> 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 ?
>
> All valid keys in the keyring are considered trusted.

This, then, highlights the problem of how one should go about keeping
this keyring up to date, and how the knowledge of a revocation of a
(possibly) compromised key or certificate should be propagated to the
users hosts, so that the associated packages are no longer accepted as
validly signed.

I'm guessing a similar problem applies to the maintenance of the
x.509-based certificates.

>> Is there a technical/operational preference for gpg vs x509 here?
>
> Technically, there are pretty much equivalent. IMO the hierachical trust
> model of x509 fits better for an organisational use case, but opinions
> differ.

My guess is that opinions differ because familiarity with the tools
most probably vary widely.  To put it mildly, not everyone is best
friends with "openssl x509" and there's at least a perception of a
steep learning curve involved: a novice such as me looking at
openssl_x509(1) is more likely to run away scared by the multitudes of
options than to acheive comprehension about how it ought to be used in
this particular application.  On the other hand, more people know and
are able to make simple use of PGP, so have at least a passing
knowledge of its use.

Note, I'm not contradicting what you say above, that x509 from a
technical standpoint might be a better fit for us, but if we're to use
it, there are still "missing procedures and policy bits, and
documentation of these" to get an effective deployment (some of that
also holds true for GPG, of course).

Regards,

- Håvard