Friday, March 25, 2011

Debian ftpmaster Meeting — Autosigning

Proposals for autosigning were floating around for quite some time. The most controversial parts were how we secure the machines that do the building (and in turn: how do we secure the key) and who's going to manage the keyring (because there are multiple teams involved; such discussions can indeed take quite a bit time).

What we've agreed upon now is as follows:
  • All buildds with autosigned must be debian.org machines, which means that they are administrated by the Debian Sysadmins. This involves regular upgrades of the machine, firewalling and monitoring. They are all doing this already (kudos!), so there was no change needed.
  • The machines must be restricted so that only a limited set of people may access it. That's done, it's just the buildd admins for the specific buildd and the global group builddadm (plus the admins and the local admin, of course).
  • Every host has its own GPG key. Key generation locally on the buildds is eased by having the fine Entropy Key hooked up to provide entropy centrally and distributed to the debian.org machines. Private keys don't need to and must not leave the host. The keys are rotated every 120 days, expiry dates will be used to ensure that and to remind us when rotation is due. Sadly there is no HSM involved. Given the geographic dispersiveness of the Debian infrastructure that's not done easily. Some machines (like s390 racks) would also be unable to connect local hardware.
  • The keys are restricted to specific architectures. They are not able to upload any source to the archive. However every binary on the specific architecture can be uploaded using the key, there are no further restrictions on package priorities or the like. They are maintained by the wanna-build admins on ftp-master by signing the armored public keys with their personal GPG keys (instructions available on the list). Thus a trust chain is established: who added or removed which key and when.
  • We plan to suppress networking in the chroot soon. This will possibly be done with unshare(1) in util-linux, as soon as we sort out proper localhost networking. This was not deemed a blocker at this point.
Kudos to Mark Hymers and Joerg Jaspert (both ftpmasters) for implementing the necessary bits on the archive side. It turned out that dak grew support for most bits already in the meantime and it boiled down to sane key management, keyring distribution and setup. sbuild and buildd needed a bit more hackery, but a few patches later it seems to work fine.

So what's the point of this exercise? The main goal is to reduce the build turnaround time. This means cleaning Dependency-Waits and Build-Depends-Uninstallable much more quickly than it used to be. (With a signing run once a day and multiple dependency levels you'd need to wait some days for a leaf package to be buildable again.) This should help speeding up transitions a fair bit. Autosigning also means getting security updates faster, at least if there's a buildd that is not occupied otherwise.

The key generation and configuration deployment will gradually happen in the next days and weeks. It will be used on the regular archive, the security archive and backports (i.e. the archives run by the ftpmasters). As some logs will still need regular signing the deployment cannot happen entirely centralized as the buildd admins need to cope with a new log format. But those steps are tiny given that we can now add keys by ourselves and the archive will even accept them.

No comments:

Post a Comment