Exportpro не вдалося знайти ключ підпису

У нас є приватне сховище debian, яке було створене роками тому попереднім системним адміністратором. Пакети були підписані старшим ключем 7610DDDE (який я повинен був відкликати), як показано тут для кореневого користувача на сервері репо.

# 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. Я змінив файл сховища / конф / розподілів, щоб використовувати новий під ключ, який я створив експліцитно для підписання:

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

Я переглядав Google і знайшов пару старих ниток, які вказували на можливу проблему з reprepro пошуку правильного каталогу 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>

І нарешті я зміг зв’язатися з адміністратором sys, який першим налаштував наші докори, і він запропонував спробувати ключ без парольної фрази. Тож я створив новий ключ підпису, DD219672, опублікував його, знову пройшов вищезазначені кроки, але з тим же результатом.

Сьогодні, після більшого читання та вивчення man-сторінок та відзначивши, що pgp-агент автоматично запускається, коли я запускаю reprepro, я вирішив переслідувати це деякий час.

Я додав gpg-agent.conf за допомогою

debug-level 7
log-file    /root/gpg.agent.log
debug-all

І я можу побачити в журналі, що gpg-агент не знаходить ключі

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-агент знаходить ключі, які він перелічує в 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-агента (це 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працював належним чином зі своїм новим ключем.

Для мене проблема полягала в тому, що я генерував ключі як користувач і запускав 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.

Сподіваюся, що це допомагає!