A package can become malicious (we consider original sources safe) either intentionally or unintentionally. In the first case packager prepares the package (by modifying sources, adding scripts, modifying build scripts) with intention to make harm to user system or data. In the second case packager by mistake or omission creates the package that if installed puts the user's system in jeopardy.
Malicious package may enter the package universe when packager provides it directly or puts it into legitimate repository or mirror. Threat level depends here on what software contained in package can do and how popular package is. The former quality is possible to determine by careful inspection of package and its contents (also running software in testing environment). The latter can be estimated by basing on download statistics (assuming that package downloaded is package installed).
So, to determine if packages are authentic, pacman uses GnuPG keys in a web of trust model. The current Master Signing Keys are found here. At least three of these Master Signing Keys are used to sign the Developer's and Trusted User's own keys. They are then used to sign their packages. Each user also has a unique PGP key, which is generated when you configure pacman-key. It is this web of trust that links the user's key to the master keys.
Examples of webs of trust:
- Custom packages: Packages made and signed with a local key.
- Unofficial packages: Packages made and signed by a developer. Then, a local key was used to sign the developer's key.
- Official packages: Packages made and signed by a developer. 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.
SigLevel option in
/etc/pacman.conf determines the level of trust required to install a package with
pacman -S. For a detailed explanation of
SigLevel, see , and the file comments. One can set signature checking globally, or per repository. If
SigLevel is set globally in the
[options] section, all packages installed with
pacman -S will require signing. With the
LocalFileSigLevel setting from the default
pacman.conf, any packages you build, and install with
pacman -U, will not need to be signed using makepkg.
Requiredis set then
DatabaseOptionalshould also be set.
For remote packages, the default configuration will only support the installation of packages signed by trusted keys:
SigLevel = Required DatabaseOptional
TrustedOnly is a default compiled-in pacman parameter. The default configuration is identical to using the global option of:
SigLevel = Required DatabaseOptional TrustedOnly
The above can be achieved too on a repository level further below in the configuration, e.g.:
[core] SigLevel = PackageRequired Include = /etc/pacman.d/mirrorlist
explicitly adds signature checking for the packages of the repository, but does not require the database to be signed.
Optional here would turn off a global
Required for this repository.
TrustAlloption exists for debugging purposes and makes it very easy to trust keys that have not been verified. You should use
TrustedOnlyfor all official repositories.
Initializing the keyring
To initialize the pacman keyring run:
# pacman-key --init
Initializing the keyring requires entropy. To generate entropy, move your mouse around, press random characters on the keyboard, or run some disk-based activity (for example in another console running
ls -R / or
find / -name foo or
dd if=/dev/sda8 of=/dev/tty7). If your system does not already have sufficient entropy, this step may take hours; if you actively generate entropy, it will complete much more quickly.
The randomness created is used to initialize the keyring (
/etc/pacman.d/gnupg) and the GPG signing key of your system.
pacman-key --initon a computer that does not generate much entropy (e.g. a headless server), key generation may take a very long time. To generate pseudo-entropy, install either haveged or rng-tools on the target machine and start the corresponding service before running
Managing the keyring
Verifying the master keys
The initial setup of keys is achieved using:
# pacman-key --populate
Take time to verify the Master Signing Keys when prompted as these are used to co-sign (and therefore trust) all other packager's keys.
PGP keys are too large (2048 bits or more) for humans to work with, so they are usually hashed to create a 40-hex-digit fingerprint which can be used to check by hand that two keys are the same. The last eight digits of the fingerprint serve as a name for the key known as the '(short) key ID' (the last sixteen digits of the fingerprint would be the 'long key ID').
Adding developer keys
The official developer and Trusted Users (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 prompt you to download it from a
keyserver configured in
/etc/pacman.d/gnupg/gpg.conf (or by using the
--keyserver option on the command line). Wikipedia maintains a list of keyservers.
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.
pacman-key --refresh-keys(as root). While doing
--refresh-keys, your local key will also be looked up on the remote keyserver, and you will receive a message about it not being found. This is nothing to be concerned about.
Adding unofficial keys
This method can be utilized to add a key to the pacman keyring, or to enable signed unofficial user repositories.
First, get the key ID (
keyid) from its owner. Then add it to the keyring using one of the two methods:
- If the key is found on a keyserver, import it with:
# pacman-key --recv-keys keyid
- If otherwise a link to a keyfile is provided, download it and then run:
# pacman-key --add /path/to/downloaded/keyfile
It is recommended to verify the fingerprint, as with any master key or any other key you are going to sign:
$ pacman-key --finger keyid
Finally, you must locally sign the imported key:
# pacman-key --lsign-key keyid
You now trust this key to sign packages.
Debugging with gpg
For debugging purposes, you can access pacman's keyring directly with gpg, e.g.:
# gpg --homedir /etc/pacman.d/gnupg --list-keys
Tips and tricks
Upgrade system regularly
Upgrading the system regularly via pacman#Upgrading packages prevents most signing errors. If delay is unavoidable and system upgrade gets delayed for an extended period, manually sync the package database and upgrade the package before system upgrade:
# pacman -Sy archlinux-keyring && pacman -Su
This command is not considered a partial upgrade since it syncs the package database and upgrades the keyring package first. Both must be processed just before starting system upgrade to ensure signatures of all upgraded packages can be properly verified.
Update system time regularly
When the system time is faulty, signing keys could be considered expired (or invalid) and signature checks on packages will fail. Synchronize the system clock regularly by using the Network Time Protocol daemon.
Invalid signature errors
pacman-key depends on system time. If your system clock is not synchronized, system installation/upgrade may fail with:
error: PackageName: signature from "User <email@example.com>" is invalid error: failed to commit transaction (invalid or corrupted package (PGP signature)) Errors occurred, no packages were upgraded.
If using ntpd, correct the system time (as root) with
ntpd -qg followed by
Other NTP clients can be used. See time synchronization.
If correction of the system clock does not resolve the failure, try one of the following approaches:
Removing packages from cache
Some packages could be corrupted or may be unsigned, causing failure. Remove each offending package from the system cache
rm /var/cache/pacman/pkg/pkgname so it gets freshly downloaded, or clear the entire cache.
Resetting all the keys
Remove or reset all the keys installed in your system by removing the
/etc/pacman.d/gnupg directory (as root) and by rerunning
pacman-key --init followed by
pacman-key --populate to re-add the default keys.
Disabling signature checking
If you are not concerned about package signing, you can disable PGP signature checking completely. Edit
/etc/pacman.conf to have the following lines under
SigLevel = Never #LocalFileSigLevel = Optional #RemoteFileSigLevel = Required
You need to comment out any repository-specific
SigLevel settings because they override the global settings. This will result in no signature checking, which was the behavior before pacman 4. If you do this, you do not need to set up a keyring with pacman-key. You can change those options later if you decide to enable package verification.
Cannot import keys
There are multiple possible sources of this problem:
- An outdated package.
- The clock being set to an incorrect date.
- Your ISP blocked the port used to import PGP keys.
- Your pacman cache contains copies of unsigned packages from previous attempts.
dirmngris not correctly configured.
You might be stuck because of an outdatedpackage when doing an upgrade synchronization.
Below are a few solutions that could work depending on your case.
Upgrade the system
See if upgrading the system can fix it first.
If you suspect that something is not working right with the keyserver, you could try to switch to the Ubuntu keyserver. To do this, edit
/etc/pacman.d/gnupg/gpg.conf and change the
keyserver line to:
Clean cached packages
If you suspect that your pacman cache at
/var/cache/pacman/pkg/ might contain unsigned packages, try cleaning the cache manually or run:
# pacman -Sc
which removes all cached packages that have not been installed.
Signature is unknown trust
Sometimes when running
pacman -Syu you might encounter this error:
error: package-name: signature from "packager" is unknown trust
This occurs because the
packager's key used in the package
package-name is not present and/or not trusted in the local pacman-key gpg database. Pacman does not seem to always be able to check if the key was received and marked as trusted before continuing. This could also be because a key has expired since it was added to your keychain.
- Manually upgrading the archlinux-keyring package prior to the system upgrade, or
- refreshing your keys with
pacman-key --refresh-keys, or
- resetting all the keys, or
- manually signing the untrusted key locally (not recommended), or
- setting temporarily
The last two options above break the chain of trust, and should be used with care.
Updating keys via proxy
In order to use a proxy when updating keys the
honor-http-proxy option must be set in both
/etc/pacman.d/gnupg/dirmngr.conf. See GnuPG#Use a keyserver for more information.
honor-http-proxyoption and fails, a reboot may solve the issue.
There is no way to stop packagers from intentionally forging packages that can do bad things to user system and providing them on their own repositories. There is however a way to make users to be more careful when downloading packages outside from official repositories, because malicious packager will have to convince users to download their package. They advertise software rich in features which provides «security, speed, ease of use» missing from the official repositories. A chance to counter this efforts is to educate user to use packages outside of official repositories only if absolutely necessary (at least until some way of preventing damage potentially caused by such software will not be devised systemwise).
Dangerous packages can also be injected on mirror level. Making this level more secure is in the hands of mirror administrators mostly but there also is a thing or two that Arch can do to help them. Downloaded packages can be verified the same way as they would be on user machine. This would demand a bit of processing power from server's side but hopefully little enough to do it.
Finally packages can be signed and their signatures automatically verified what in connection with provided database of trusted packagers will lower the possibility of installing dangerous package from untrusted source.
Arch Linux has relatively small and educated user base which makes it unlikely target of malicious packages based attack but it does not mean that obvious gaps in security should not be taken care of, especially when talking about package security.