Difference between revisions of "Pacman/Package signing"

From ArchWiki
Jump to navigation Jump to search
m (Configuring pacman: minor updates)
Line 82: Line 82:
{{bc|# pacman-key --lsign-key <keyid>}}
{{bc|# pacman-key --lsign-key <keyid>}}
You now trust this key to sign packages.
You now trust this key to sign packages.
===By gpg===
If pacman-key is not enough, you can manage pacman's keyring by '''gpg''' like this:
# gpg --homedir /etc/pacman.d/gnupg $OPTIONS
# env GNUPGHOME=/etc/pacman.d/gnupg gpg $OPTIONS

Revision as of 15:26, 5 June 2012

This template has only maintenance purposes. For linking to local translations please use interlanguage links, see Help:i18n#Interlanguage links.

Local languages: Català – Dansk – English – Español – Esperanto – Hrvatski – Indonesia – Italiano – Lietuviškai – Magyar – Nederlands – Norsk Bokmål – Polski – Português – Slovenský – Česky – Ελληνικά – Български – Русский – Српски – Українська – עברית – العربية – ไทย – 日本語 – 正體中文 – 简体中文 – 한국어

External languages (all articles in these languages should be moved to the external wiki): Deutsch – Français – Română – Suomi – Svenska – Tiếng Việt – Türkçe – فارسی

pacman-key is a new tool available with pacman 4. It allows the user to manage pacman's list of trusted keys in the new package signing implementation.

How it works

Package signing in pacman uses the "web of trust" model to ensure that packages come from the developers and not from someone impersonating them. Package developers and TUs have individual PGP keys which they use to sign their packages. This signature means they vouch for the contents of the package. You also have a unique PGP key which is generated when you set up pacman-key.

Keys can also be used to sign other keys, which means the owner of the signing key vouches for the authenticity of the signed key. In order to trust a package, you need to have a chain of signatures from your own PGP key to the package itself. With the Arch key structure, this can happen in three ways:

  • Custom packages: You made the package yourself and signed it with your own key.
  • Unofficial packages: A developer made the package and signed it. You used your key to sign that developer's key.
  • Official packages: A developer made the package and signed it. The developer's key was signed by the Arch Linux master keys. You used your key to sign the master keys, and you trust them to vouch for developers.

For some background on this issue, see these blog entries [1][2][3][4] and the package signing proposal wiki page.


Configuring pacman

First, you need to decide what level of checking you want. This is configured using the SigLevel option in /etc/pacman.conf. Several possibilities are mentioned in the comments in that file, and you can read the pacman.conf man page for full details. Basically, you can allow signature checking globally or per repository. Keep in mind that if you set the SigLevel globally in the [options] section, you will not be able to install your own packages using pacman -U anymore if they are not signed by a trusted key.

Warning: The SigLevel TrustAll option exists for debugging purposes and makes it very easy to trust keys that have not been verified. You should use TrustedOnly for all official repositories.
Note: As of April 2012, database signing has not been implemented yet, so you will need to add the DatabaseOptional option if you use Required, for example:
SigLevel = Required DatabaseOptional TrustedOnly
This way pacman will only install packages that are signed by keys that you trust.
Note: It looks like SigLevel = PackageRequired is going to be standard for verifying official packages:
SigLevel = PackageRequired
Include = /etc/pacman.d/mirrorlist

Initializing keyring

To set up the pacman keyring use:

# pacman-key --init

This will set up a new keyring in /etc/pacman.d/gnupg and generate a unique master key for your system. For pacman to start checking package signatures you have to import the developers keys to your keyring. The next section explains how to do so.

Managing the keyring

The keys which are needed to verify package signatures are stored in a "keyring" managed by pacman-key. When a key is needed which is not in the keyring, pacman and pacman-key can retrieve it from a keyserver. The keyserver to use is configured in /etc/pacman.d/gnupg/gpg.conf, and you can override it by using the --keyserver option on the command line. (If you are looking for different keyservers, you can find a short list on the Wikipedia article.)

PGP keys are usually too large (2048 bits or more) for humans to work with, so they are usually hashed to create a 40-hex-digit fingerprint. The last eight digits are known as the key ID, and are used as a "name" for the key. The longer fingerprint is used when you want to check by hand that two keys are the same.

Master keys

There are five Arch Linux master keys which are used to sign the keys of developers and TUs. These keys should be in your keyring, signed by you and given a marginal level of trust for pacman to trust these PGP keys.

 # for key in 6AC6A4C2 824B18E8 4C7EA887 FFF979E7 CDFD6BB0; do pacman-key --recv-keys $key; pacman-key --lsign-key $key; printf 'trust\n3\nquit\n' | gpg --homedir /etc/pacman.d/gnupg/ --no-permission-warning --command-fd 0 --edit-key $key; done
Warning: You should check if master keys above match these fingerprints.

Official developer keys

The official developer and TU keys are signed by the master keys, so you do not need to use pacman-key to sign them yourself. Whenever pacman encounters a key it does not recognize, it will ask you if you want to download it from a keyserver. Once you have downloaded a developer key, you will not have to download it again, and it can be used to verify any other packages signed by that developer.

If the developer's and TU's keys were added some time ago, their signatures by the master keys might not be present in the local keyring database. To have uptodate keys run as root :

# pacman-key --refresh-keys
Note: While doing --refresh-keys, your local key will also be looked up on the remote keyserver, and you will receive a message about it being not found. This is nothing to be concerned about.

Importing Developers and Trusted Users Keys

Get all keys from Arch Linux developers and Trusted Users on a shot (taken from this thread):

# curl https://www.archlinux.org/{developers,trustedusers}/ | awk -F\" '(/pgp.mit.edu/) {sub(/.*search=0x/,"");print $1}' | xargs pacman-key --recv-keys
Warning: You should check if the shown keys' fingerprints match these fingerprints.
Note: The above command will add all developer and trusted users keys, bypassing PGP's Web of Trust concept. A better alternative is to use archlinux-keyring

Arch Linux provides the archlinux-keyring package that will automatically load your keyring with the master and developers keys when installed. It will also contain updated keys eliminating need for executing pacman-key --refresh-keys. If you do not have the master keys in your keyring when you install this package, it will ask you to sign the master keys.

Warning: Installing archlinux-keyring before enabling package validation may cause dangerous results in case of a hacked mirror or intercepted connection. Ensure you have enabled package validation in /etc/pacman.conf and added the correct Master Signing Keys before installing the package.

Unofficial keys

If you want to add an unofficial key to your keyring, you will need to do it manually using pacman-key. First, get the ID from the owner of the key. Run:

# pacman-key -r <keyid>

to download it from a keyserver. Be sure to verify the fingerprint, as you would with a master key, or any other key which you are going to sign. After verifying the fingerprint, you need to locally sign this key:

# pacman-key --lsign-key <keyid>

You now trust this key to sign packages.

By gpg

If pacman-key is not enough, you can manage pacman's keyring by gpg like this:

# gpg --homedir /etc/pacman.d/gnupg $OPTIONS


# env GNUPGHOME=/etc/pacman.d/gnupg gpg $OPTIONS


How can I collect entropy?

Moving your mouse around, pressing random characters at the keyboard or running some disk-based activity e.g. updatedb in another virtual console can solve it. It may take a while so please be patient.

If you need to run pacman-key --init over ssh, build and install the rng-toolsAUR package from the AUR on the target machine. Connect via ssh and do the following:

# sed -i 's/0/10/' /etc/conf.d/rngd
# rngd -f -r /dev/urandom &
# pacman-key --init

After pacman-key successfully runs simply stop rngd and remove the package.

# killall rngd
# pacman -Rns rng-tools

Cannot import keys

Some ISPs block the port used to import PGP keys. One solution is to use the MIT keyserver, which provides an alternate port. To do this, edit /etc/pacman.d/gnupg/gpg.conf and change the keyserver line to:

keyserver hkp://pgp.mit.edu:11371

Disabling signature checking

Warning: Use with caution. Disabling package signing will allow pacman to install untrusted packages automatically.

If you are not concerned about package signing, you can disable PGP signature checking completely. Edit /etc/pacman.conf and uncomment the following line under [options]:

SigLevel = Never

You need to comment out any repository-specific SigLevel settings too because they override the global settings. This will result in no signature checking, which was the behavior before pacman 4. If you decide to do this, you do not need to set up a keyring with pacman-key. You can change this option later if you decide to enable package verification.

Resetting all the keys

If you want to remove or reset all the keys installed in your system, you can remove /etc/pacman.d/gnupg folder as root and rerun pacman-key --init and following that add the keys as preferred.