ArchLinux and I aren’t the best of friends, its rolling release system just doesn’t jive with me. I only really installed it on a couple personal servers for experience with another distribution, so usually the boxes sit there doing their thing until I feel like setting up something new. When I run its first update in six months, something usually goes wrong, and I make my way over to their forums to figure out how to give pacman a kick in the butt to get things sorted.

This time around, I’m installing metasploit to test some equipment against the recent security flaws in UPnP that have been making some waves. A binary package isn’t available in the official repositories so in this case the Arch User Repository (AUR) picks up the slack to automate building from source. I’ve used this in the past with some success, but last year Arch finally implemented package signing. Turns out this complicates installing these personally built packages unless you temporarily disable it. Let’s not do that though, let’s stay consistent with package signing. In a larger environment with your own custom repo, you would definitely want to have this working, and there’s nothing wrong with learning more about your system.

First step in package signing is to have your own key to sign with. If you’re like me and don’t have one, you can create this key using gpg --gen-key. You’ll be prompted for information to identify the key with like your full name and email address, and a password to secure your private key with. Defaults for the key pair type and length (2048 bits) are fine.

When that’s all done, you can export an ASCII copy of your public key with gpg, identified by the name you chose previously, and import that into your pacman trustdb using pacman-key. I feel this method is preferable to using a public key server unless you’re interested in using gpg for public activities. If you’re sharing your binary packages with other servers, using a public key server would save you the trouble of copying the ASCII public key around to each of them.

After that, you sign the key with the local pacman master key and trust it. To do that you need the key ID shown in the previous steps as ABCD1234.

With that done, it’s time to tell makepkg to start signing custom packages. You can edit the systemwide config at /etc/makepkg.conf, but as you’re defining a name and signing key it makes more sense to have a local config for your build user located in ~/.makepkg.conf.

In this local config, you enable sign (default is !sign in /etc/makepkg.conf), and specify the packager and your GPG key. With that done, you should be good to go to run makepkg again, this time being prompted for the password to your private key.

With the .xz and its .sig file created, pacman is happy to install your new, signed package!