Fedora Signing Server Spec
Problem Statement and Scope
This document aims to specify the mechanism for gpg signing rpm packages and other files within the Fedora infrastructure. This mechanism proposal includes both a Server component and a Client component.
Core Goals
The core goals of a signing server are as follows
Security
Security is extremely important to the Fedora project and the signing server specifically. The signing server will be used to digitally sign rpm packages and other files which the Fedora project will make available to the general user base. These digital signatures are designed to ensure that the software users are installing came from the Fedora project and are not trojaned software. Ensuring that only appropriate people have access to sign packages is extremely important to the continued trust in the Fedora project. As such the Signing Server /must/ be secure.
Separation of "Who can sign" from "Who knows the gpg passphrase"
In the past, those that were "allowed" to sign were given the gpg passphrase for the key in question. This does not work well as it is extremely difficult to revoke such signing access. For that reason the signing server should have the concept of allowing people to sign, but without them having to know the passphase.
Conserve User Bandwidth
In order to conserve bandwidth, the signing server should work with Koji to sign/import/write out signed packages directly rather than passing signed copies back to the client. Clearsigned files or detached signatures may still be handed directly to the client from the server, but these are usually small and the bandwidth cost is not high.
Design
The design of the signing server will consist of at least two components. A server side component that does the actual signing of packages and files and a client side component that requests the signing of packages and files. The client may be implemented in both command line and web forms.
Server Component
The Server Component will be a python XMLRPC server. It will be responsible for the following:
Authenticating Clients
The server component will need a method to authenticate client requests for build(s) signing. The Fedora Account System should be used as part of Fedora's single sign-on goals. Each available gpg key should have a list of who is allowed to sign with it.
rpm-sign packages
Input should be in the form of a set of paths or rpm names that need to be signed and which key to sign them with. These would be generated by the client with interaction to koji to determine which rpm files need to be signed. The signing server will create copies of the unsigned paths in a work dir and sign them with the requested key. Validation will be done to ensure that the packages are in fact signed correctly. What the server should do with these signed packages is still up for design. Either import into koji directly, hand back the signed header for the client to import, or hand back to the client a path reference to where the signed package exists. Design considerations to take into account, usefulness in environments outside koji, dependence of a working koji account, bandwidth considerations.
Clearsign Files
There are a number of files that we have to gpg clear sign. These include SHA1SUM files for iso directories. Given that these files are small and easy to transport it would be easiest to just pass the file in from the client and return a signed version to the client.
Client Component
The client component will be responsible for the following:
Provide credentials to the server component
In order to authenticate a client request, credentials of the user requesting the signing must be provided to the server.
Generate manifest of packages + key
A properly formatted manifest of packages + key must be generated and provided to the server component.
Koji provides the capability of (multiple) cached gpg signatures for each build. This allows the same build to be signed with multiple keys, as well as keeping just cached signatures instead of the entire signed copy of the rpms. As such the client needs to take advantage of these capabilities when generating a manifest of what to sign. Since koji can have signed headers imported but no file written out the client will need to determine which packages need signing and importing, vs which just need written out. Whether the client itself determines all this, or some higher level client does and hands off the list to a simple client is also up for design consideration. Keeping it simple has advantages in that the signing server/client pair could be used with non-koji systems.
Display results to user
Results of the signing request must be provided to the user or calling app. If the results are a signed file that file obviously has to be dealt with.