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:
Public interfaces
rsync: keyring.debian.org::keyrings
This is the most important public interface; it's the one that the
Debian infrastructure uses. This is
where ftp-master gets its
information shortly after it is updated, for example. 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.
Salsa: https://salsa.debian.org/debian-keyring/keyring/
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 salsa. Finally gbp buildpackage --builder='sbuild -d sid' tells-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.)