gpgで署名の信頼を検証しますか？

gpg署名を使用して、システム構成管理ツールのいくつかの側面を検証したいと思います。さらに、個々のsysadminキーがマスター署名キーで署名される「信頼」モデルを使用し、システムはそのマスターキーを信頼します（そして、「信頼の輪」を使用してシステム管理者による署名を検証します）。

これにより、誰かが去ったときにキーの信頼を簡単に取り消すことができるなど、多くの柔軟性が得られますが、問題が発生しました。一方でgpg、コマンドがします教えて鍵が信頼できない場合、あなたが、その旨を示す終了コードを返すように表示されません。例えば：

# gpg -v < foo.asc
Version: GnuPG v1.4.11 (GNU/Linux)
gpg: armor header: 
gpg: original file name=''
this is a test
gpg: Signature made Fri 22 Jul 2011 11:34:02 AM EDT using RSA key ID ABCD00B0
gpg: using PGP trust model
gpg: Good signature from "Testing Key <someone@example.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: ABCD 1234 0527 9D0C 3C4A  CAFE BABE DEAD BEEF 00B0
gpg: binary signature, digest algorithm SHA1

私たちが気にする部分はこれです：

gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.

この場合、gpgが返す終了コードは、信頼の失敗にもかかわらず0です。

# echo $?
0

信頼できない署名で何かが署名された場合、どうすればgpgを失敗させることができますか？

gpgvコマンドが適切な終了コードを返すという提案を見てきましたが、残念ながらgpgvキーサーバーからキーを取得する方法を知りません。からのステータス出力（--status-fdを使用）を解析できると思いますgpgが、もっと良い方法はありますか？

これが最終的には次のとおりです。

#!/bin/sh

tmpfile=$(mktemp gpgverifyXXXXXX)
trap "rm -f $tmpfile" EXIT

gpg --status-fd 3 --verify "$@" 3> $tmpfile || exit 1
egrep -q '^\[GNUPG:] TRUST_(ULTIMATE|FULLY)' $tmpfile

これは、にgpg出力する信頼情報を探します--status-fd。信頼できない署名（または無効/署名なし）が存在する場合、スクリプトはエラーで終了します。

$ sh checksig sample.sh.bad 
gpg: Signature made Mon 24 Jun 2013 11:42:58 AM EDT using RSA key ID DCD5C569
gpg: Good signature from "Test User <testuser@example.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 6FCD 3CF0 8BBC AD50 662E  5070 E33E D53C DCD5 C569
$ echo $?
1

有効で信頼できる署名が存在する場合、スクリプトはエラーなしで終了します。

$ sh checksig sample.sh.good
gpg: Signature made Mon 24 Jun 2013 11:38:49 AM EDT using RSA key ID 5C2864A8
gpg: Good signature from "Lars Kellogg-Stedman <...>"
$ echo $?
0

だから私は問題を分割してみましょう：

最初の問題は、テスト対象のキーが信頼されていないようです。

gpg -v < test.txt.asc 
gpg: armor header: Version: GnuPG v1.4.11 (GNU/Linux)
gpg: original file name='test.txt'
this is a test
gpg: Signature made Thu 11 Aug 2011 09:09:35 PM EST using RSA key ID FE1B770E
gpg: using PGP trust model
gpg: Good signature from "John Doe <jdoe@noemail.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 5DD8 216D ADB1 51E8 4326  3ACA 1DED BB72 FE1B 770E
gpg: binary signature, digest algorithm SHA1

これは意図的なものだと思いますが、修正方法を説明する前に、gpg -vの代わりにgpgvを使用することをお勧めします。理由はすぐにわかります。

$ gpgv < test.txt.asc 
gpgv: keyblock resource `/user/.gnupg/trustedkeys.gpg': file open error
gpgv: Signature made Thu 11 Aug 2011 09:09:35 PM EST using RSA key ID FE1B770E
gpgv: Can't check signature: public key not found

$ echo $?
2

キーなし、信頼なし...いいえ、キーをtrustedkeys.gpgにインポートします

$ gpg --no-default-keyring --keyring trustedkeys.gpg --import jdoe_pub.gpg
gpg: keyring `/user/.gnupg/trustedkeys.gpg' created
gpg: key FE1B770E: public key "John Doe <jdoe@noemail.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
$ gpgv < test.txt.asc 
gpgv: Signature made Thu 11 Aug 2011 09:09:35 PM EST using RSA key ID FE1B770E
gpgv: Good signature from "John Doe <jdoe@noemail.com>"

$ echo $?
0

それが役に立てば幸い

2つのオプションが思い浮かびます（出力の解析以外）。

迅速で汚い方法は、 gpgとの両方を実行することgpgvです。の最初の実行でgpgは、キーがキーサーバーから取得されたことを確認してから、gpgv必要な戻りコードを提供します。

（より多くの作業が必要になりますが）よりエレガントで制御された方法は、gpgmeライブラリを使用して署名を検証することです。Perl、PHP、Python、Rubyのラッパーがありますが、Cライブラリです。（Pythonのものは非常に低レベルですが、Rubyのものはいくつかのより高いレベルの抽象化を持っていますが、PerlやPHPについてはわかりません）。

GPGMEライブラリは、使用したときにキーサーバーと通信しているように見えますが、確認してください。私は少し書いてきたルビーGPGMEライブラリを使用するコードを（の検索verifyとverified_ok?検証その署名、および用のコードのためのsig_output_lines署名が信頼されているかどうかうまくいくいくつかのコードのため）。

システム構成をPuppetやChefなどのツールに移行するのはどうですか？

些細な作業ではありませんが、Chef（私はPuppetを使用していません）では、ユーザーアカウントを作成する必要があります（およびpub / privateキーが生成されます）。これは、サーバー上のローカルファイルの変更を防ぐことはできませんが、chef-clientは定期的に実行され、次回の実行時に変更を上書きします。（デフォルトで定期的な繰り返し実行が行われます。）