tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Obstacles to get signed binary pkgs



* On 2020-01-31 at 10:35 GMT, Martin Husemann wrote:

> On Fri, Jan 31, 2020 at 09:46:04AM +0000, Jonathan Perkin wrote:
> 
> Thanks a lot, very helpful! Skipping the technical details for now...
> 
> > These are the questions I can't answer.  NetBSD is going to be
> > different to all the other OS that have package signing enabled, as
> > you ship pkg_install with the OS.  For us it's easy, we distribute the
> > pkg_install bootstrap kit bundled with all the bits necessary for
> > verifying its signed packages.
> > 
> > As an added bonus we also include the pkgsrc-security key so that the
> > vulnerabilities file can be verified out of the box, and distribute
> > this as a package so that it can be updated whenever the key changes.
> > This is configured with GPG_KEYRING_PKGVULN in pkg_install.conf.
> 
> Is the following a practical aproach?
> 
>  - We add the NetBSD security officer public key (as of the time a release
>    is generated) to our (base system) distribution, e.g. as part of the
>    "etc" set.
> 
>  - We assume that binaries to a each individual pkg repository (i.e. ftp
>    server directory) are build by a single build environment. Each gets
>    a signing key (not necessarily unique) and the public key of that
>    is stored at the root of the pkg repository, and officially
>    signed by the NetBSD security officer. The pkgsrc-security key
>    with same handling too.
> 
>  - We can switch keys any time we start a pkg build from scratch. Or the
>    other way around: if we need to switch keys, all pkgs need to be
>    rebuild.

I don't really know to be honest.  I know that I initially tried to
use subkeys in my setup so that I could switch between them easily and
create a new set per release, but ran into bugs in gnupg that
prevented me from doing this.  I don't remember exactly the details,
but something about not being able to select between different subkeys
when they were all available or something (I build all the different
releases on the same hardware).

I'm not really the best person to ask about key signing things.  I
utterly hate the whole thing.  Our setup is far from perfect, but it
feels like any changes I'd need to make to improve it, for example
generating per-release keys or implementing offline signing, would
either fall foul of gnupg, or create massive infrastructure headaches.

It also creates headaches about how you handle upgrades.  Our users
expect to be able to either follow a rolling trunk release or switch
between the quarterlies, and at some point they'd need to switch to a
different verification key.

Sorry, that probably doesn't answer your question very well...

-- 
Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com


Home | Main Index | Thread Index | Old Index