У нас есть частный репозиторий Debian, который был создан несколько лет назад одним из более ранних системных администраторов. Пакеты были подписаны старым ключом 7610DDDE (который мне пришлось отозвать), как показано здесь для пользователя root на сервере репо.
# gpg --list-keys
/root/.gnupg/pubring.gpg
------------------------
pub 1024D/2D230C5F 2006-01-03 [expired: 2007-02-07]
uid Debian Archive Automatic Signing Key (2006) <ftpmaster@debian.org>
pub 1024D/7610DDDE 2006-03-03 [revoked: 2016-03-31]
uid Archive Maintainer <root@xxxxxxxxxx.com>
pub 4096R/DD219672 2016-04-18
uid Archive Maintainer <root@xxxxxxxxxx.com>
Все команды ниже от имени пользователя root. Я изменил файл repository / conf / distributions, чтобы использовать новый подключа, который я явно создал для подписи:
Architectures: i386 amd64 source
Codename: unstable
Components: main
...
SignWith: DD219672
Но когда я использую dput для обновления пакета, я получаю
Could not find any key matching 'DD219672'!
ERROR: Could not finish exporting 'unstable'!
This means that from outside your repository will still look like before (and
should still work if this old state worked), but the changes intended with this
call will not be visible until you call export directly (via reprepro export)
И когда я запускаю непосредственно экспорт реппро, я получаю:
# reprepro -V export unstable
Exporting unstable...
generating main/Contents-i386...
generating main/Contents-amd64...
Could not find any key matching 'DD219672'!
ERROR: Could not finish exporting 'unstable'!
Я googledd и нашел пару старых потоков, которые указали на возможную проблему с репрезпро, находящей правильный каталог gnupg ... поэтому я попробовал это с теми же результатами, что и выше:
# GNUPGHOME=/root/.gnupg reprepro -V export unstable
Один поток предложил проверить ключ, подписав фиктивный файл, который, казалось, работал нормально ... по крайней мере, он не сообщил об ошибках, и я получил 576-байтовый файл bla.gpg после его завершения.
# touch bla
# gpg -u DD219672 --sign bla
На странице руководства реппро также предлагается: «Если есть проблемы с подписью, вы можете попробовать gpg - list-secret-keys значение чтобы увидеть, как gpg может интерпретировать значение. Если эта команда не перечисляет какие-либо ключи или несколько ключей, попробуйте найти какое-нибудь другое значение (например, keyid), которое gpg может легче связать с уникальным ключом ». Я проверил и это, и получил:
# gpg --list-secret-keys DD219672
sec 4096R/DD219672 2016-04-18
uid Archive Maintainer <root@xxxxxxxxxx.com>
И, наконец, я смог связаться с системным администратором, который первым настроил наши репро, и он предложил попробовать ключ без парольной фразы. Итак, я сгенерировал новый ключ подписи DD219672, опубликовал его, снова повторил описанные выше шаги, но с тем же результатом.
Сегодня, после дополнительного чтения и изучения страниц руководства и заметив, что pgp-agent запускается автоматически, когда я запускаю команду реппро, я решил какое-то время заняться этим.
Я добавил gpg-agent.conf с
debug-level 7
log-file /root/gpg.agent.log
debug-all
И я вижу в журнале, что gpg-agent не находит ключи
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK Pleased to meet you, process 18903
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- RESET
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- OPTION ttyname=/dev/pts/0
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- OPTION ttytype=xterm-256color
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- GETINFO version
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> D 2.1.11
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- OPTION allow-pinentry-notify
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- OPTION agent-awareness=2.1.0
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- AGENT_ID
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> ERR 67109139 Unknown IPC command <GPG Agent>
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- HAVEKEY C2C5C59E5E90830F314ABB66997CCFAACC5DEA2F 416E8A33354912FF4843D52AAAD43FBF206252D9 8CE77065EA6F3818A4975072C8341F32CB7B0EF0
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> ERR 67108881 No secret key <GPG Agent>
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- [eof]
Мне пока не удалось выяснить, где gpg-agent находит ключи, которые он перечисляет в HAVKEY, и как указать ему в правильном направлении, чтобы найти новый ключ DD219672 для подписи наших обновленных пакетов.
У меня была та же проблема, и после долгого разочарования я наконец понял, что происходит.
В reprepro инструмент использует gpgme, который основан на gnupg2. Недавний выпуск изменил способ работы с секретным связкой ключей: https://www.gnupg.org/faq/whats-new-in-2.1.html
gpg используется для хранения пар открытых ключей в двух файлах:
pubring.gpgиsecring.gpg... В GnuPG 2.1 это изменилось ... Чтобы упростить переход на метод без защиты, gpg обнаруживает наличиеsecring.gpgи на лету конвертирует ключи в хранилище ключей gpg-agent (этоprivate-keys-v1.dкаталог под домашним каталогом GnuPG (~/.gnupg)). Это делается только один раз и существующийsecring.gpgтогда gpg больше не касается. Это позволяет сосуществовать более старым версиям GnuPG с GnuPG 2.1. Однако любое изменение закрытых ключей с использованием нового gpg не будет отображаться при использовании версий GnuPG до 2.1 и наоборот.
Таким образом, если вы создадите новый ключ с помощью gpg, gpg2 не увидит его, и наоборот.
Быстрое исправление, которое сработало для меня:
gpg --export-secret-keys | gpg2 --import -
И если нужно пойти другим путем, конечно:
gpg2 --export-secret-keys | gpg --import -
В зависимости от ваших настроек вы также можете захотеть / нуждаться в добавлении --export-secret-subkeys
После выполнения вышеуказанного reprepro работал правильно с моим новым ключом.
Для меня проблема заключалась в том, что я сгенерированные ключи как пользователь и Запустил реппро как root.
Произошло то, что я создал ключи "без sudo"добавлены к моему локальному pubring.gpg. Когда я бегу sudo reprepro ... Я запускаю его как root, поэтому он пытается найти ключ в корневом каталоге pubring.gpg и явно не находит.
Решением было запустить все gpg команды как root (ур. sudo -i а потом gpg --gen-key). Убедитесь, что когда вы бежите sudo gpg --list-keys вы видите желаемые ключи и строку /root/.gnupg/pubring.gpg.
Надеюсь, это поможет!