Не удалось найти экспорт подписи.

У нас есть частный репозиторий 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. Я изменил файл репозитория / conf / distribution, чтобы использовать новый дополнительный ключ, который я создал для подписи:

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'!

Я гуглил и нашел пару старых потоков, которые указывали на возможную проблему с представлением процентной информации о правильном каталоге gnupg ... поэтому я попробовал это с теми же результатами, что и выше:

# GNUPGHOME=/root/.gnupg reprepro -V export unstable

Один поток предложил протестировать ключ, подписав фиктивный файл, который, кажется, работал нормально ... по крайней мере, он не сообщил об ошибках, и я получил файл bla.gpg размером 576 байт после его завершения.

# 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, опубликовал его, снова выполнил описанные выше шаги, но с тем же результатом.

Сегодня, после дополнительного чтения и изучения man-страниц и того, что pgp-agent автоматически запускается, когда я запускаюPoint Propro, я решил немного поработать над этим.

Я добавил 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 обнаруживает присутствие a secring.gpgи конвертирует ключи на лету в хранилище ключей gpg-agent (это private-keys-v1.dкаталог под домашним каталогом GnuPG ( ~/.gnupg)). Это делается только один раз, и secring.gpggpg больше не затрагивает существующее. Это позволяет сосуществовать с более старыми версиями 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, и поэтому он пытается найти ключ в root pubring.gpgи, очевидно, не находит его.

Решением было запустить все gpgкоманды от имени пользователя root (например, sudo -iзатем gpg --gen-key). Убедитесь, что при запуске sudo gpg --list-keysвы видите нужные ключи и строку /root/.gnupg/pubring.gpg.

Надеюсь, это поможет!