Package Signing/GPG Key Management Questions

[Michael Schwendt]

On Mon, 24 Jul 2006 12:49:29 -0400, Chris wrote:

> Could someone shed light on the process for GPG signing of packages in
> the Extras repository?

Limited knowledge only: A few people (from Red Hat and the community) have
access to the key and its pass-phrase. Packages built on the build clients
are collected by the build master [server] and stored in the "needsign"
queue. The packages from that queue are not published into the master
repository automatically. The people with access to the key need to start
a manual process (aka the extras-push script) which prompts for the
pass-phrase, signs the packages and installs them into the master
repository as appropriate.

> I briefly searched the archives, but found only
> an inconclusive argument about its usefulness.

What have you found? Obviously, signed packages (particularly when signed
manually) have the benefit that they cannot be modified once they enter
the network of repository mirrors. And it is not possible to infiltrate
any repository with faked signed packages as long as you don't have access
to the key (and passphrase in this case).

> How does the Extras package signing process differ from Base/Updates?

Only somebody who knows the Core signing-process can answer that.

> I know RPM-GPG-KEY-fedora-extras sits alongside RPM-GPG-KEY-fedora, but
> who has control of the Extras signing key? 

The group mentioned above.

> Is checking for a CLA on
> file the extent of vetting done to submitted packages (assuming they
> meet all other packaging criteria outlined in the Wiki)?

Currently, the CLA and sponsorship (by an Extras contributor who has got
"sponsor" privileges) are the prerequisites to getting access to CVS and
the build system for submission of build jobs.

> It would be most helpful to have a sketch of what the ultimate signer (a
> RH employee?) does before he/she decides it's OK to sign the package
> with the official fedora-extras key.

With the high number of packages which are built and upgraded every day,
it is impossible for a human being to apply any security relevant
post-build checks to individual packages.  Verifying binary rpms without
examining src.rpm tarball contents and build dependency chains is
impossible.  Monitoring of CVS commits, builds and releases must be done
by the entire community of Users, Developers and Packagers. It is
particularly important that packagers peruse the build logs they receive
from the build system.  Plus, the system administrators must keep all
servers involved secure.