web-dev-qa-db-ja.com

Repreproエクスポートで署名鍵が見つかりませんでした

私たちには、何年も前に以前のシステム管理者によって設定された非公開の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)  <[email protected]>

pub   1024D/7610DDDE 2006-03-03 [revoked: 2016-03-31]
uid                  Archive Maintainer <[email protected]>

pub   4096R/DD219672 2016-04-18
uid                  Archive Maintainer <[email protected]>

以下のコマンドはすべて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エクスポートを直接実行すると、次のようになります。

# 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ディレクトリを見つけるrepreproで問題の可能性があることを示す古いスレッドをいくつか見つけたので、上記と同じ結果でこれを試しました:

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

1つのスレッドが、正常に動作しているように見えるダミーファイルに署名してキーをテストすることを提案しました...少なくともエラーは報告されず、終了後に576バイトのbla.gpgファイルになりました。

# touch bla
# gpg -u DD219672 --sign bla

Repreproのmanページには、「署名に問題がある場合はgpg --list-secret-keys valueを試してgpgが値をどのように解釈できるかを確認することもできます。そのコマンドでキーがリストされない場合または、複数のもの、他の値(keyidなど)を見つけてみてください。そのgpgは、一意のキーとより簡単に関連付けることができます。」だから私もそれをチェックして得ました:

# gpg --list-secret-keys DD219672
sec   4096R/DD219672 2016-04-18
uid                  Archive Maintainer <[email protected]>

そして最後に、最初に再現を設定したシステム管理者に連絡することができ、パスフレーズなしでキーを試すことを提案しました。そこで、新しい署名鍵DD219672を生成して公開し、上記の手順をもう一度実行しましたが、結果は同じでした。

今日、manページをよく読んで調べ、repreproを実行すると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を見つけて更新されたパッケージに署名するためにそれを正しい方向に向けるかを理解できていません。

14
Andy Dorman

私も同じ問題を抱えていましたが、苛立ちを募らせた後、ようやく何が起こっているのかを突き止めました。

repreproツールは、gnupg2に基づくgpgmeを使用します。その最近のリリースでは、秘密鍵リングの処理方法が変更されました: https://www.gnupg.org/faq/whats-new-in-2.1.html

公開鍵のペアを2つのファイルに保存するためにgpgを使用:pubring.gpgおよびsecring.gpg ... GnuPG 2.1ではこれが変更されました...非保護メソッドへの移行を容易にするために、gpgはa secring.gpgキーをオンザフライでgpg-agentのキーストアに変換します(これはGnuPGホームディレクトリ(private-keys-v1.d)の下の~/.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は私の新しいキーで適切に動作しました。

19
Cheetah

私にとっての問題は、私がユーザーとして生成されたキーおよびrootとしてrepreproを実行であることでした。

Sudoなし」で生成したキーがローカルのpubring.gpgに追加されたのです。 Sudo reprepro ...を実行すると、ルートとして実行されるため、ルートのpubring.gpgでキーを見つけようとしますが、明らかにキーが見つかりません。

解決策は、すべてのgpgコマンドをrootとして実行することでした(例:Sudo -i、次にgpg --gen-key)。 Sudo gpg --list-keysを実行すると、目的のキーと行/root/.gnupg/pubring.gpgが表示されることを確認してください。

お役に立てば幸いです。

2
Dmytro Bogatov