This page attempts to describe the various public interfaces to the Debian keyring, and explain the ways in which they differ. It is important to realise that they are not all equal in order to understand why a submitted keyring update may not yet be visible to the Debian infrastructure. This may be the case even though keyring-maint has said the update has been performed, or it is visible via some of the public interfaces already. Equally a key update may be visible to the Debian infrastructure despite not being updated somewhere, for example in the debian-keyring package in the archive.

First, a diagram to show the different interfaces to the keyring and how they connect to each other:

keyring-maint workflow

Public interfaces

rsync: keyring.debian.org::keyrings

This is the most important public interface; it's the one that the Debian infrastructure uses. It's the canonical location of the active set of Debian keyrings and is what you should be using if you want the most up to date copy. The validity of the keyrings can be checked using the included sha512sums.txt file, which will be signed by whoever in keyring-maint did the last keyring update.

HKP interface: hkp://keyring.debian.org/

What you talk to with gpg --keyserver keyring.debian.org. Serves out the current keyrings, and accepts updates to any key it already knows about (allowing, for example, expiry updates, new subkeys + uids or new signatures without the need to file a ticket in RT or otherwise explicitly request it). Updates sent to this interface will be available via it within a few hours, but must be manually folded into the active keyring. This in general happens about once a month when preparing for a general update of the keyring; for example b490c1d5f075951e80b22641b2a133c725adaab8.

Why not do this automatically? Even though the site uses GnuPG to verify incoming updates there are still occasions were bugs have been seen (such as #787046, where GnuPG would always import subkeys it didn't understand, even when that subkey was already present). Also it is not desirable to allow just any UID to be part of the keyring. It is thus useful to retain a final set of human based sanity checking for any update before it becomes part of the keyring proper.

Alioth/anonscm: https://anonscm.debian.org/git/keyring/keyring.git/

A public mirror of the git repository the keyring-maint team use to maintain the keyring. Every action is recorded here, and in general each commit should be a single action (such as adding a new key, doing a key replacement or moving a key between keyrings). Note that pulling in the updates sent via HKP count as a single action, rather than having a commit per key updated. This mirror is updated whenever a new keyring is made active (i.e. made available via the rsync interface). Until that point pending changes are kept private; keyring-maint sometimes deals with information such as the fact someone has potentially had a key compromised that shouldn't be public until it has actually been disabled. Every “keyring push” (as the process of making a new keyring active is referred to) is tagged with the date it was performed. Releases are also tagged with their codenames, to make it easy to do comparisons over time.

Debian archive

This is actually the least important public interface to the keyring, at least from the perspective of the keyring-maint team. No infrastructure makes use of it and while it's mostly updated when a new keyring is made active a concerted effort to do so is only made when it is coming up to release. It's provided as a convenience package rather than something which should be utilised for active verification of which keys are and aren't currently part of the keyring.

Team interface

Master repository: kaufmann.debian.org:/srv/keyring.debian.org/master-keyring.git

The master git repository for keyring maintenance is stored on kaufmann.debian.org AKA keyring.debian.org. This system is centrally managed by DSA, with only DSA and keyring-maint having login rights to it. None of the actual maintenance work takes place here; it is a bare repo providing a central point for the members of keyring-maint to collaborate around.

Private interface

Private working clone

This is where all of the actual keyring work happens. Team members have a local clone of the repository from kaufmann on a personal machine. The key additions / changes are performed here, and are then pushed to the master repository so that they're visible to the rest of the team. When preparing to make a new keyring active the changes that have been sent to the HKP interface are copied from kaufmann via scp and folded in using the pull-updates script. The tree is assembled into keyrings with a simple make and some sanity tests performed using make test. If these are successful the sha512sums.txt file is signed using gpg --clearsign and the output copied over to kaufmann. update-keyrings is then called to update the active keyrings (both rsync + HKP). A git push public pushes the changes to the public repository on anonscm. Finally gbp buildpackage --git-builder='sbuild -d sid' tells git-buildpackage to use sbuild to build a package ready to be uploaded to the archive.

(This is a modified version of an article that originally appeared on Jonathan's blog.)