I have previously covered the more technical aspects of the implementation of PGP signing of packages and repository databases in pacman. You can read the previous entries here:
Since then, pacman-4.0 has been released and has been in the [testing] repository in Arch Linux for a while. That means that the signing implementation is starting to get some more widespread usage. No major issues have been found, but there are some areas that could be improved (e.g. the handling of the lack of signatures when installing packages with -U – FS#26520 and FS#26729). And it has successfully detected a “bad package” in my repo… (well, not really a bad package, but a bad signature. Lesson: do not try creating detached signatures for multiple files at once because gnupg is crap…).
The Arch repos have been gradually preparing for the package signature checking in pacman-4.0. Support for uploading PGP signatures with packages was added in April and was made mandatory from the beginning of November. As of today, 100% of the packages in the [core] repo and approximately 71% of [extra] and 45% of [community] are signed.
So all the components are coming together nicely. But how does this work from a practical standpoint? I’ll start with setting up the pacman PGP keyring and pacman.conf.
When first installing pacman-4.0, you should initialize your pacman keyring using pacman-key --init. This creates the needed keyring files (pubring.gpg, secring.gpg) with the needed permissions, updates the trust database (obviously empty at this point…), and generates a basic configuration file. It also generates the “Pacman Keychain Master Key”, which is your ultimate trust point for starting a PGP web of trust. You may want to change the default keyserver in the configuration file (/etc/pacman.d/gnupg/gpg.conf) as some people have issues connecting to it.
The set-up of your pacman.conf file is somewhat a matter of personal preference, but the values I use are probably reasonable… I have the global settings for signature checking as the default value (Optional TrustedOnly). This basically sets the need for signatures to be optional, but if they are there then the signature has to be from a trusted source. See the pacman.conf man page for more details. For the Arch Linux repos with all packages signed, I set PackageRequired which forces packages to be signed but not databases. (For the small repo I provide, I use Required as both packages and databases are signed.)
Lets look at some output when installing a signed package:
# pacman -S gcc-libs
warning: gcc-libs-4.6.2-3 is up to date -- reinstalling
resolving dependencies...
looking for inter-conflicts...
Targets (1): gcc-libs-4.6.2-3
Total Installed Size: 2.96 MiB
Net Upgrade Size: 0.00 MiB
Proceed with installation? [Y/n]
(1/1) checking package integrity [######################] 100%
error: gcc-libs: key "F99FFE0FEAE999BD" is unknown
:: Import PGP key EAE999BD, "Allan McRae ", created 2011-06-03? [Y/n] y
(1/1) checking package integrity [######################] 100%
error: gcc-libs: signature from "Allan McRae " is unknown trust
error: failed to commit transaction (invalid or corrupted package (PGP signature))
Errors occurred, no packages were upgraded.
As you can see, pacman struck a package that had a signature from an unknown key. It then asks if you would like to import that key. Given the PGP key fingerprint matches that published in multiple places, importing that key seems fine. Then pacman errors out due to that key not being trusted. Well, that Allan guy seems reasonably trustworthy… so I could just locally sign that key using pacman-key --lsign EAE999BD and that key will now be trusted enough to install packages.
Validating every Arch Linux Developer’s and Trusted User’s PGP key would soon become annoying as there are a fair number of them (35 devs and 30 TUs – with some overlap). To make this (a bit…) simpler, five “Master Keys” have been provided for the Arch Linux repositories. The idea behind these keys is that all developer and TU keys are signed by these keys and you only need to import and trust these keys in order to trust all the keys used to sign packages. These key fingerprints will be published in multiple places so that the user can have confidence in them (see the bottom of this post for a listing of the fingerprints obtained relatively independently of those listed on the Arch website).
To set-up your pacman keyring with these keys, you can do something like:
for key in FFF979E7 CDFD6BB0 4C7EA887 6AC6A4C2 824B18E8; do
pacman-key --recv-keys $key
pacman-key --lsign-key $key
printf 'trustn3nquitn' | gpg --homedir /etc/pacman.d/gnupg/
--no-permission-warning --command-fd 0 --edit-key $key
done
That will import those keys into your keyring and locally sign them. But that is not quite enough as those keys are not used to sign packages themselves. In order for pacman to trust PGP keys signed by the master keys you have to assign some level of trust to the master keys. The final line gives the master keys “marginal” trust. Note I use gpg directly rather than pacman-key as pacman-key does not understand the --command-fd option. You could use pacman-key --edit-key if you wanted to manually type in the commands to set the trust level. By default, the PGP web of trust is set up such that if a key is signed by three keys of marginal trust, then that key will be trusted. (We have five master keys rather than the minimal three so that we can revoke two – a worst case scenario… – and still have our packages trusted.) Note that setting the master keys to have marginal trust serves as a further safety mechanism as multiple keys would need to be hijacked to create a key that is trusted by the pacman keyring.
Now that the five master keys are nicely imported into your pacman keyring, any time pacman strikes a package from the Arch Linux repos with a signature from a key it does not know, it will import the key and it will automatically be trusted. At least that is the idea… We are still in a transition period so not all Developer and Trusted User keys are fully signed yet by the master keys yet, but we are not too far off. In the future we might provide a pacman-keyring package that streamlines this process a bit, or at least will save the individual downloading of each packager’s key.
That just leaves the signing of the databases, but that is a story for another day!
—
Arch Linux Master Key fingerprints:
Allan McRae – AB19 265E 5D7D 2068 7D30 3246 BA1D FB64 FFF9 79E7
Dan McGee – 27FF C476 9E19 F096 D41D 9265 A04F 9397 CDFD 6BB0
Ionuț Mircea Bîru – 44D4 A033 AC14 0143 9273 97D4 7EFD 567D 4C7E A887
Pierre Schmitz – 0E8B 6440 79F5 99DF C1DD C397 3348 882F 6AC6 A4C2
Thomas Bächler – 6841 48BB 25B4 9E98 6A49 44C5 5184 252D 824B 18E8
So I decided to create a very simple theme based on the archlinux-simplyblack theme provided in the archlinux-themes-slim package. I dislike all the options crap typically displayed in a login manager, so this theme will not show a user selection dialog, session manager, keyboard layout changer, language selection or even a quit dialog, no matter what your configuration is. Also my guess is that this theme only works with the GTK greeter given I have not tested anything else…