Package signing as implemented in certification

Introduction

A general overview of package signing could be found here and in the references therein. This document is to describe how package signing is implemented in certification.

Procedure for the certification team

Follow the steps described below:
  • Setting up the infrastruucture:
    • Generate a key likee this
    • Generate a revocation certificate like this. Probably this will not be used, but always good to have one.
    • Back up the key in this way
    • Nominate a place where publick key will be published, and circulate this information using the relevant lists and tools only after the whole prcedure has been tested.
    • Since package managers cannot handle public (remote/netwok) keyrings we do not upload the public key to any keyring.
    • Nominate 2 people who is allowed to own the key and who know the password, they will be the signing responsible persons (SRPs), they should have a common and unique contact point (email, jabber, whatever), i.e. a certifier should not know in advance which SRP is on duty a given time.

  • Operation
    • When a certifier certified a patch triggers the SRP contact asking for signing the relevant rpm. This should be a formal message/mail having a commonly agreed format. For example by moving the patch to 'Certified' in Savannah, Savannah itself sends a message.
    • The SRP on duty acknowledges the request in the shortest possible time and signs the rpms and sends an other notif when the signing is done. (May these notif could be attached to the patch later on.) While the sending of message can be scripted the signing itself should not be integrated together with a script performing other functionalities (like move patch). The signing script should only sign and should be executed manually. The time scale between the trigger and the acknowledgement should be in the order of some 10 minutes. If this turns out to put a too high load on the SRPs we can reviese this policy.
    • After signing the rpm the SRP sets the patch state ('Signed') and moves the patch (physically) to the appropriate place. It can be Savannah itself sending the ack message about the signing. Being Savannah the tool sending the message we will have the timing information between the various steps.
  • Transition
    • Only the packages went through on the above procedure should be signed. Old packages in the repository should not be signed, because a.) you cannot be sure anymore that the packages in the repo are indeed the ones have been certified some month/year ago, b.) it would introduce a (not too serious) problem of versioning/rebuilding, etc...
    • Since there are a lot of package which are changing very slowly, they will be signed only in the far future, which questions the seriousity of the whole process, since signing is really meaningful only if every pacakge in a repository is signed. This fact points toward the whole re-certification of the gLite stack smile frown
    • Thus, in this transition period one (ex. YAIM) should maintain a (signed) list about the signed rpms, and check only that ones.
    • Since the duration of this transition period can easily extend a year or so, the validity of the generated key should be greater than that in order to avoid extra complications.

For site administrators

This section describes various procedure for site administrators for several package manager.

The RPM package manager

  • Importing the public key to keystore
    1. Download the key: =wget http://certif-website/certpub.gpg=
    2. Set your GPGHOME enviromental variable to point to your gpg home: export GPGHOME=/root/.mygpg
    3. Import the public key to the keyring: gpg --import certifkey.key
    4. Check that the key has been imported with : rpm -q gpg-pubkey --qf '%{name}-%{version}-%{release} --> %{summary}\n'
  • Verifying packages
    1. Check that the key is imported.
    2. Execute: rpm -K package.rpm
  • Removing the key from the keystore

The YUM package manager

The APT package manager

-- GergelyDebreczeni - 04 Feb 2009

Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r2 - 2009-02-10 - GergelyDebreczeni
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EGEE All webs login

This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright & by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Ask a support question or Send feedback