Управление связкой ключей
Проверка мастер-ключей
Первоначальная настройка ключей выполняется командой:
# pacman-key --populate archlinux
PGP-ключи довольно велики (2048 бит или больше), что делает их неудобными для восприятия людьми. Поэтому на основе ключа вычисляется 40-разрядная шестнадцатеричная хэш-сумма, по которой можно проверить его подлинность. Также нужно помнить, что последние восемь цифр хэш-суммы часто используют как имя или (короткий) ID ключа, а последние шестнадцать — как длинный ID ключа.
Добавление ключей разработчика
Ключи официальных разработчиков и доверенных пользователей подписываются мастер-ключами, так что вам не нужно использовать pacman-key, чтобы подписывать их самостоятельно. Когда pacman встречает в подписи пакета ключ, который не удаётся распознать, то предлагает скачать его с сервера ключей, указанного в параметре в файле или в опции командной строки. Перечень серверов ключей можно найти в Википедии.
Ключ разработчика нужно скачать всего единожды, после этого он будет использоваться для проверки любого пакета от этого разработчика.
Примечание: Пакет , являющийся зависимостью для , содержит самые свежие на момент последнего обновления ключи. При необходимости ключи можно также обновить вручную командой с правами root. При выполнении этой команды pacman-key попытается найти на сервере ключей также и ваш локальный ключ, после чего выдаст сообщение, что ключ не найден — это нормально.
Добавление неофициальных ключей
Этим способом можно добавить в связку ключей pacman свой ключ или включить подписанный неофициальный репозиторий.
В первую очередь получите у владельца ключа его ID (). Добавьте полученный ключ в связку:
- Если ключ находится на сервере ключей, импортируйте его командой:
# pacman-key --recv-keys keyid
- Если у вас есть ссылка на файл ключа, скачайте его и выполните:
# pacman-key --add /путь/к/скачанному/файлу/ключа
Всегда старайтесь проверять отпечаток — как мастер-ключей, так любых других ключей, которые вы собираетесь подписать:
# pacman-key --finger keyid
Наконец, подпишите импортированный ключ локально:
# pacman-key --lsign-key keyid
Теперь этот ключ будет считаться доверенным.
Отладка при помощи gpg
При отладке доступ к связке ключей pacman можно получить напрямую с помощью gpg, например:
# gpg -- homedir /etc/pacman.d/gnupg --list-keys
Errors about Keys
We all have our own unique signatures which are used to authenticate who we are and to prevent fraudulent or even malicious activities by others. This is also the case with software packages available from the software repositories. They all contain encrypted codes (signature keys) unique to their developers to ensure that they are authentic and not malicious in nature.
During the installation process, once any software packages have been downloaded, your system will first check their signature keys to ensure that they are authentic prior to actually installing them. If a signature key cannot be verified for any reason, then the installation process will be aborted. This problem will usually occur due to:
- one or more signature keys contained in your system’s database being revoked, changed, corrupted, or out of date
- one or more software packages not having been signed off properly when placed in a repository
Where a package has not been signed off properly before being placed in a repository, it will be the responsibility of the developer(s) to correct this. However, as this problem will be more than likely due to a problem with your system’s verification of a signiture key, this can be solved in three easy steps. Working net connection is required. Once you have opened your terminal:
WarningThe following commands only work, when your system time is set correctly!
1. Remove old (and possibly broken) keys by entering this command:
sudo rm -r /etc/pacman.d/gnupg
2. Reinstall keyrings including the latest keys:
sudo pacman -Sy gnupg archlinux-keyring manjaro-keyring
2. Initialize the pacman keyring:
sudo pacman-key --init
4. Load the signature keys:
sudo pacman-key --populate archlinux manjaro
5. Refresh and update the signature keys:
sudo pacman-key --refresh-keys
6. Clear out the software packages downloaded during the aborted installation (optional):
sudo pacman -Sc
INFOImproved version added, since it doesn’t work that way above. The packages are signed and since /etc/pacman.d/gnupg has been removed, it cannot be installed due the check. Instead editing the /etc/pacman.conf and lowering the SigLevel, it would be better installing the keyrings without a check manually to overcome this problem.
1. Remove old (and possibly broken) keys by entering this command:
sudo rm -r /etc/pacman.d/gnupg
2. Initialize the pacman keyring:
sudo pacman-key --init
3. Download the packages:
sudo pacman -Syw gnupg archlinux-keyring manjaro-keyring --cachedir $HOME/.cache/
4. Remove the signatures:
rm -f $HOME/.cache/*.sig
5. Install the downloaded packages manually:
INFOThis will also trigger the populate process.
sudo pacman -U $HOME/.cache/*.tar.zst
6. Clear out the software packages downloaded during the aborted installation (optional):
sudo pacman -Sc
WarningThe above command clears the pacman cache completely, and one will not be able to downgrade to a previous version of a package if required. Instead packages that are causing signing errors can be removed individually when upgrading.
After that try running sudo pacman -Syu to see if the errors were resolved.
Setup
Configuring pacman
The option in determines the level of trust required to install a package. For a detailed explanation of , see and the file comments. One can set signature checking globally or per repository. If is set globally in the section, all packages will then require signing. Any packages you build will then need to be signed using makepkg.
The default configuration will only support the installation of packages signed by trusted keys:
/etc/pacman.conf
SigLevel = Required DatabaseOptional
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.:
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. here would turn off a global for this repository.
Warning: The SigLevel option exists for debugging purposes and makes it very easy to trust keys that have not been verified. You should use for 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 or or ). 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 () and the GPG signing key of your system.
Note: If you need to run on 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 .
Решение проблем
error: signature from xxx is invalid
Важно: Работа pacman-key зависит от настроек системного времени. Если системные часы неверны, при обновлении вы получите следующую ошибку:
error: PackageName: signature from "User <email@archlinux.org>" is invalid error: failed to commit transaction (invalid or corrupted package (PGP signature)) Errors occured, no packages were upgraded.
Эта ошибка связана с gpg. Она означает, что пакет на диске не сооветствует пакету, который был подписан его сопроводителем. Выяснить причину может быть непросто, но в большинстве случаев удаление файла и скачивание его заново решает проблему. И в любом случае, такое сообщение об ошибке свидетельствует о проблеме с gpg и ключами, которые используются для подписывания пакетов.
Ниже приведены три возможных решения. Если вы не уверены, что выбрать, попросите о помощи на форуме.
Удаление старых версий пакетов
Если постоянно возникает проблема с одним и тем же пакетом и вы уверены, что дело не в pacman-key, попробуйте удалить плохой пакет из кэша командой и скачайте его заново.
Удаление пакета из кэша может помочь при ошибке , произошедшей при обновлении. Такое сообщение не обязательно является свидетельством атаки «человек-посередине» — возможно, пакет просто был повреждён при скачивании.
Сброс ключей
Для сброса всех установленных в системе ключей необходимо удалить каталог . После этого выполните команды и , чтобы добавить базовый набор ключей заново.
Отключение проверки подписи
Важно: Используйте с осторожностью. Отключение проверки подписи приведёт к тому, что pacman будет без возражений устанавливать любые пакеты, в том числе и недоверенные.
Если подписи пакетов вас не интересуют, можно полностью отключить их проверку
Отредактируйте файл , раскомментировав следующую строку в разделе :
Если подписи пакетов вас не интересуют, можно полностью отключить их проверку. Отредактируйте файл , раскомментировав следующую строку в разделе :
SigLevel = Never
Также необходимо закомментировать все параметры SigLevel в настройках репозиториев, потому что они имеют приоритет над глобальными настройками. В результате подпись пакетов проверяться не будет, как это было в pacman до четвертой версии. В этом случае устанавливать связку ключей при помощи pacman-key не нужно. Позже при необходимости можно будет включить проверку подписи пакетов обратно.
Не удаётся импортировать ключи
Возможные причины:
- Устаревший пакет ;
- Неправильные настройки даты и времени;
- Интернет-провайдер блокирует порт, используемый для импорта PGP-ключей;
- Кэш pacman содержит неподписанные пакеты, оставшиеся с предыдущих попыток;
- Демон не был правильно настроен;
- Вы давно не обновлялись и gpg/pacman не справились с обновлением.
Давно не обновлявшийся пакет может привести к проблемам при синхронизации обновлений.
Ниже приведено несколько возможных решений.
Смена сервера ключей
Если вы предполагаете, что проблема связана с сервером ключей, то можно попробовать переключиться на сервер ключей Ubuntu. Отредактируйте файл , изменив значение :
keyserver hkp://keyserver.ubuntu.com
Удаление кэшированных пакетов
Возможно, кэш pacman в каталоге содержит неподписанные пакеты. Очистите кеш вручную:
# pacman -Sc
что удалит все пакеты в кэше, которые не были установлены.
Не удаётся опознать подпись пакета
Иногда при выполнении вы можете столкнуться со следующей ошибкой:
error: название_пакета: signature from "создатель_пакета" is unknown trust
Такое происходит, когда ключ создателя пакета отсутствует в локальной базе данных pacman-key или не является доверенным. Pacman не всегда имеет возможность проверить, был ли ключ скачан и является ли он доверенным, перед тем как продолжить обновление. Также возможно, что срок действия ключа истёк.
Возможные решения:
- обновить ключи командой ;
- ;
- ;
- временно установить параметр в значение (не рекомендуется).
Примечание: Если pacman-key был запущен без опции и все равно завершился с ошибкой, попробуйте перезагрузиться.
Tips and tricks
Flushing passphrases
$ gnome-keyring-daemon -r -d
This command starts gnome-keyring-daemon, shutting down previously running instances.
Git integration
The GNOME keyring is useful in conjunction with Git when you are pushing over HTTPS. The package .
Configure Git to use the libsecret helper:
$ git config --global credential.helper /usr/lib/git-core/git-credential-libsecret
The next time you run , you will be asked to unlock your keyring if it is not already unlocked.
GnuPG integration
Several applications which use GnuPG require a to be set. Set the following to use GNOME 3 pinentry for GNOME Keyring to manage passphrase prompts.
~/.gnupg/gpg-agent.conf
pinentry-program /usr/bin/pinentry-gnome3
Another option is to which should allow the passphrase to be entered in the application.
Automatically change keyring password with user password
Note: This only affects the default keyring.
Add to the end of .
/etc/pam.d/passwd
#%PAM-1.0 #password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3 #password required pam_unix.so sha512 shadow use_authtok password required pam_unix.so sha512 shadow nullok password optional pam_gnome_keyring.so
Настройка
Настройка pacman
Настройка по умолчанию позволяет устанавливать только те пакеты, которые подписаны доверенными ключами:
/etc/pacman.conf
SigLevel = Required DatabaseOptional
Параметр используется в pacman по умолчанию, то есть настройка ниже аналогична предыдущей:
SigLevel = Required DatabaseOptional TrustedOnly
То же самое можно задать и для отдельного репозитория далее в файле конфигурации:
SigLevel = PackageRequired Include = /etc/pacman.d/mirrorlist
Здесь явно задаётся проверка подписи для пакетов из этого репозитория, но подпись базы данных не проверяется. Если задать здесь значение , то для этого репозитория глобальное значение станет недействительно.
Важно: SigLevel даёт системе указание считать все ключи доверенными. Эта значение используется только для целей отладки
Для официальных репозиториев необходимо использовать значение .
Инициализация связки ключей
Для инициализации связки ключей pacman выполните:
# pacman-key --init
Для инициализации необходима энтропия. Чтобы сгенерировать больше энтропии, активно двигайте мышью, нажимайте случайные клавиши или выполняейте действия, связанные с диском (например, запустите в другой консоли , или ). Если энтропия системы недостаточна, этот этап может занять часы; активная генерация энтропии ускорит процесс.
Генерируемая последовательность случайных чисел используется для создания связки ключей () и GPG-ключа вашей системы.
Примечание: Если вы запускаете на компьютере, который не генерирует много энтропии (например, на удалённом сервере), создание ключа может занять очень много времени. Для выработки псевдоэнтропии установите утилиты haveged или rng-tools и запустите соответствующую службу перед командой .
Ошибка pacman «The requested URL returned error: 404»
Для работы менеджера пакетов имеется кэш — в этом кэше собрана информация о существующих пакетах для установки, их версиях и ссылки на скачивание. Чтобы обновить (или скачать впервые) этот кэш, нужно выполнить команду:
sudo pacman -Sy
После этого можно выполнять обновление системы или обновление пакета.
Если кэш устарел и вы пытаетесь установить пакет, версия которого обновилась и для которого в вашем локальном кэше старая ссылка, вы можете получить примерно следующую ошибку:
error: failed retrieving file 'goaccess-1.4.5-1-x86_64.pkg.tar.zst' from mirrors.evowise.com : The requested URL returned error: 404
Для её исправления нужно выполнить приведённую выше команду, а затем повторить установку.
Но аналогичная проблема может возникнуть при запуске обновления системы — это странно, поскольку следующая команда начинает с обновления кэша, следовательно, кэш самый новый и ошибка «файл не найден» не должна возникать:
sudo pacman -Syu
Эта команда привела к ошибке:
error: failed retrieving file 'goaccess-1.4.5-1-x86_64.pkg.tar.zst' from mirrors.evowise.com : The requested URL returned error: 404 error: failed retrieving file 'goaccess-1.4.5-1-x86_64.pkg.tar.zst' from mirror.rackspace.com : The requested URL returned error: 404 error: failed retrieving file 'goaccess-1.4.5-1-x86_64.pkg.tar.zst' from mirror.rackspace.com : The requested URL returned error: 404 error: failed retrieving file 'goaccess-1.4.5-1-x86_64.pkg.tar.zst' from mirror.dkm.cz : The requested URL returned error: 404 error: failed retrieving file 'goaccess-1.4.5-1-x86_64.pkg.tar.zst' from mirror.dkm.cz : The requested URL returned error: 404 error: failed retrieving file 'goaccess-1.4.5-1-x86_64.pkg.tar.zst' from europe.mirror.pkgbuild.com : The requested URL returned error: 404 .................................................................... .................................................................... .................................................................... warning: failed to retrieve some files error: failed to commit transaction (failed to retrieve some files) Errors occurred, no packages were upgraded.
Многократное повторение команды ничего не меняет.
Причина в следующем: pacman скачивает кэш с некачественного зеркала, в котором содержится неверная информация. Для исправления, нужно выбрать другое зеркало, или переместить другое зеркало вверх списка, если вы используете несколько зеркал.
Начнём с того, что переключимся на новый список зеркал. Дело в том, что при установке пакета pacman-mirrorlist (в этом пакете содержится список зеркал), новый файл /etc/pacman.d/mirrorlist не заменяет существующий, а сохраняется с именем /etc/pacman.d/mirrorlist.pacnew. То есть даже если у вас последняя версия пакета pacman-mirrorlist, это не означает, что у вас актуальная версия файла /etc/pacman.d/mirrorlist. Проверте, существует ли файл /etc/pacman.d/mirrorlist.pacnew:
ls -l /etc/pacman.d/mirrorlist.pacnew
Если файл существует, то выполните следующие две команды (в противном случае пропустите их):
sudo mv /etc/pacman.d/mirrorlist /etc/pacman.d/mirrorlist.back sudo mv /etc/pacman.d/mirrorlist.pacnew /etc/pacman.d/mirrorlist
Это не всё — дело в том, что в файле /etc/pacman.d/mirrorlist по умолчанию все зеркала закомментированы, то есть отключены. Чтобы это исправить, откройте данный файл:
sudo gedit /etc/pacman.d/mirrorlist
и раскомментируйте, то есть удалите символ # в начале строки. Выберите те зеркала и страны, которые ближе к вам.
В моём случае проблемным зеркалом, вызвавшим описанную выше ошибку, стало следующее (не используйте его):
#Server = http://mirrors.evowise.com/archlinux/$repo/os/$arch
Tips and tricks
Upgrade system regularly
Upgrading the system regularly via 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.
Managing the keyring
Verifying the master keys
The initial setup of keys is achieved using:
# pacman-key --populate archlinux
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 configured in (or by using the 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.
Note: The package, which is a dependency of , contains the latest keys. However keys can also be updated manually using (as root). While doing , 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 article or section needs expansion.
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 () 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
Troubleshooting
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@archlinux.org>" 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 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 so it gets freshly downloaded, or .
Resetting all the keys
Remove or reset all the keys installed in your system by removing the folder (as root) and by rerunning followed by to re-add the default keys.
Disabling signature checking
Warning: Use with caution. Disabling package signing will allow pacman to install untrusted packages.
If you are not concerned about package signing, you can disable PGP signature checking completely. Edit and uncomment the following line under :
SigLevel = Never
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 this option later if you decide to enable package verification.
Cannot import keys
This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.
There are multiple possible sources of this problem:
- An outdated package.
- Incorrect date.
- Your ISP blocked the port used to import PGP keys.
- Your pacman cache contains copies of unsigned packages from previous attempts.
- is not correctly configured
- you have not upgraded in a long time and gpg/pacman does not handle that well
You might be stuck because of an outdated package when doing an upgrade synchronization.
Below are a few solutions that could work depending on your case.
Change keyserver
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 and change the line to:
keyserver hkp://keyserver.ubuntu.com
Clean cached packages
If you suspect that your pacman cache at 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 you might encounter this error:
error: package-name: signature from "packager" is unknown trust
This occurs because the ‘s key used in the package 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.
Mitigate by:
- Refreshing your keys with , or
- , or
- , or
- setting temporarily to (not recommended).
Note: If pacman-key is used without the option and fails, a reboot may solve the issue.
Using the keyring
The PAM module pam_gnome_keyring.so initialises GNOME Keyring partially, unlocking the default login keyring in the process. It should be followed by a call to gnome-keyring-daemon with the option to complete initialisation and to set environment variables.
PAM step
Note: To use automatic unlocking without automatic login, the password for the user account should be the same as the default keyring. See .
Tip:
- To use automatic unlocking with automatic login, you can set a blank password for the default keyring. Note that the contents of the keyring are stored unencrypted in this case.
When using a display manager, the keyring works out of the box for most cases. GDM, LightDM, LXDM, and SDDM already have the necessary PAM configuration. For a display manager that does not automatically unlock the keyring edit the appropriate file instead of as mentioned below.
When using console-based login, edit :
Add at the end of the section and at the end of the section.
/etc/pam.d/login
#%PAM-1.0 auth required pam_securetty.so auth requisite pam_nologin.so auth include system-local-login auth optional pam_gnome_keyring.so account include system-local-login session include system-local-login session optional pam_gnome_keyring.so auto_start
If you are using GNOME, Unity, Cinnamon, or MATE, you are done. The initialisation is completed and environment variables are set automatically.
—start step
If you are not using GNOME, Unity, Mate, or Cinnamon as your desktop environment, initialisation will not complete automatically. You can fix this using various methods:
Shell
Add the following to your , , or similar:
~/.bash_profile
if ;then
eval $(gnome-keyring-daemon --start)
export SSH_AUTH_SOCK
fi
~/.config/fish/config.fish
if test -n "$DESKTOP_SESSION"
set -x (gnome-keyring-daemon --start | string split "=")
end
xinitrc
Start the gnome-keyring-daemon from xinitrc:
~/.xinitrc
eval $(gnome-keyring-daemon --start) export SSH_AUTH_SOCK
XDG autostart
Copy , , and from to and delete the lines from each file. Note however that this will not set (and the other variables if the PAM step was skipped) environment variable.
«Unable to lock database» Error
When downloading and installing software from the repositories, a special database lock file will be created in order to ensure that the current installation process is the only one running at that time. Otherwise, attempting to install multiple files from multiple sources simultaneously may corrupt the downloaded files, cause file conflicts — or worse still — damage your system. Once the installation has been completed, the lock file will then be automatically deleted. This error may therefore occur due to two possible reasons:
- Another installation is still taking place and has not yet finished, or
- A previous installation attempt had not finished properly (e.g. due to being aborted early)
It is therefore wise to first check to ensure that another installation is not (or had not been) in process at the time of the error. When satisfied that this is not the case, then the database lock file can be manually deleted. To do so, open up the terminal and enter the following command:
sudo rm /var/lib/pacman/db.lck
Once done, you should now be able to successfully re-attempt your intended installation.
