Libelektra: テストは無制限のgpg-agentsを生成します

問題を報告していただきありがとうございます！

@ petermax2テスト中にgpgコマンドがgpg-agentsを生成する可能性はありますか？

おっと、gpgは常に同じエージェントに接続すると思いました。 調査します。

@ markus2330これは、

しかし、問題はdockerに限定されていません：debian-stretch-minimalには250を超えるものもあります

一部のノードは、テストで使用されるjenkinsのgpg-agentを生成するように設定されているため、影響を受けません（おそらく確認する必要があります）

これを調べてくれてありがとう！

一部のノードは、テストで使用されるjenkinsのgpg-agentを生成するように設定されているため、影響を受けません（おそらく確認する必要があります）

開始したエージェントを強制終了する方法が見つからない場合は、環境にすでにgpg-agent（＃1888）があることを要求できます。

たぶん、gpgエージェントはまったく起動する必要がなく、テスト中にそれを抑制することができます。 しかし、私は夕方にそれを見なければなりません。

mhは通常、開始時にGPG_AGENT_INFOを設定する必要があります。過去には、環境変数をクリーンアップして、過去の複数の開始を説明した可能性があります。 なぜ今もまだ起こっているのか分かりませんが...

@ petermax2 gpg-agentを必要とするテスト（gpg-agentの名前をgpg-agent.bakに変更して見つかりました;））：

• testmod_fcrypt
• testmod_crypto_openssl
• testmod_crypto_gcrypt

testmod_crypto_botanは、 testmod_crypto_gcryptおよびtestmod_crypto_opensslとまったく同じように実行する必要があります。 Botanテストはサーバーで実行されていますか？

@ petermax2おそらくそうです。 私がテストした環境では、ボタンはインストールされていませんでした。 ただし、ここでは実行さ

それほど単純ではありません。 単体テスト中に--no-autostart引数を指定してgpgを呼び出そうとしましたが、gpgはまだエージェントを起動します。 --no-use-agentは面白いものです。 マニュアルページには次のように書かれています。

--no-use-agent 
              This is dummy option. gpg2 always requires the agent.

開始したエージェントを強制終了する方法が見つからない場合は、環境にすでにgpg-agent（＃1888）があることを要求できます。

これを試してみませんか？

または、次のようなcronジョブがあります

pgrep gpg-agent | xargs -d "\n" kill

またはビルドサーバー/コンテナで同様のもの？

エージェントが利用可能かどうかをテストチェックします。利用できない場合は、エージェントを起動してpidを保持します。 テストクリーンアップでエージェントを停止します。 他のすべてはハックです。

あなたは正しいです、唯一の問題は開始と停止がどこで起こるべきかです。 エージェント/ドッカー内でこれを行うことは、Cで記述された単体テストよりも簡単なようです。

これが私がこれまでに学んだことです：

すべてのgpg呼び出しで一貫して使用されている場合は、 --no-autostartオプションを使用してgpg-agentの自動開始を抑制することができます。 ただし、 gpg-agentがないと、 gpg2は、秘密鍵を必要とする操作（つまり、復号化、署名）を実行できません。

gpg-agent --serverをフォークすることもできますが、 gpg2はエージェントに接続できません。 環境変数GPG_AGENT_INFOは非推奨になり、 gpg2では考慮されなくなりました。

gpg-agent --daemonをフォークして実行しようとします。 テストが完了したときにSIGTERMを実行できるように、開始されたgpg-agentのPIDを見つける方法が必要です。

エージェント/ドッカー内でこれを行うことは、Cで記述された単体テストよりも簡単なようです。

はるかに簡単だと思います:-)

gpgのデフォルトの方法を使用してエージェントに接続するというあなたの決定は正しかったと思います。

gpg-agentを開始/停止する代わりに、.gnupg /gpg.confの「use-agent」を無効にすることもできます。

1つのエージェントの自動起動に問題はありません（さらには実行しています）。 新しいテストを開始する後続のテストに問題があります

gpgのデフォルトの方法を使用してエージェントに接続するというあなたの決定は正しかったと思います。

実稼働環境では、これがより適切なオプションです。 私のマシンでは、 cryptoとfcrypt常に同じエージェントに接続し、Yubikeyとの統合は非常にうまく機能します。

テスト環境では、テストを開始する前に、エージェントの単一インスタンスを稼働状態に保つ必要があります。 問題は、@ ingwinluが前述したように、環境をクリアすることだと思います。

問題は、環境をクリアすることだと思います

もうすべきではありません。 しかし、問題は解決しません

gpg-agentが明らかに機能しない環境を介して通信しようとした場合、次のテスト実行では、前のテスト実行で設定された環境が取得されることはありません。

私は次の2つのオプションが一番好きです：

1. コンテナ内のgpgエージェントを適切に開始/停止し、gpgエージェントを実行する必要があることをTESTING.mdに記録します（＃1888を参照）。
2. gpgエージェントの起動を無効にし（.gnupg / gpg.confの「use-agent」を無効にしますが、テストはしませんでした）、これをTESTING.mdに記録します（＃1888を参照）。

デーモンがすでに開始されているかどうかをグローバルに知る方法なしにデーモンがオンデマンドで開始されるセットアップ（およびenv変数はグローバルではなくプロセス固有）は壊れているようです。 テスト内でこれを修正しようとすべきではありません。

https://stackoverflow.com/questions/27459869/how-to-stop-gpg-2-1-spawning-many-agents-for-unit-testing

多くのエージェントを生成する理由は、-homedirオプションを使用する別のホームディレクトリです。そうでない場合は、単一のホームディレクトリが使用されます。 GnuPG 2.1以降、エージェントとのすべての通信は、GnuPGホームディレクトリのソケットを介して実行されます。

homedirオプションは使用しません。 また、 https ：//dev.gnupg.org/T3218では、stackoverflowの回避策を「（非常に厄介な）回避策」と説明しています。

たぶん、単にgpg-agentを起動することが、（私たちの環境内で制御された方法で）最も将来性のあるバリアントです。 最近のバージョンでは、gpg-agentの起動はオプションではなくなったようです。 （これは私のオプション2を無意味にします）

homedirオプションは使用しません。

ええ、それがどこから来たのかはわかりませんが、すべてのエージェントが別のエージェントでスポーンしたため、問題と一致します（opを参照）。

それは良いヒントでした、私はgpg-agentの起動がもはやオプションではないことを学びました。

これは、それを開始および停止する必要があることを非常に明確にしています。 そして、開始を避けようとしないでください。

homedirオプションは使用しません。

ええ、どこから来たのかわかりませんが、問題と一致します（opを参照）

--home-dirオプションを明示的に使用していませんが、 ps -ef 、 gpgがとにかくそれを設定していることを示しています。

https://wiki.archlinux.org/index.php/GnuPG

$ GNUPGHOMEは、構成ファイルが保存されているディレクトリを指すためにGnuPGによって使用されます。 デフォルトでは、$ GNUPGHOMEは設定されておらず、代わりに$ HOMEが使用されます。 したがって、インストール直後に〜/ .gnupgディレクトリが見つかります。
デフォルトの場所を変更するには、この方法でgpgを実行する$ gpg --homedir path / to / fileまたは、GNUPGHOME環境変数を設定します。
`` `
@ petermax2テストスイートでHOMEが利用可能かどうかを確認できますか？

また興味深いhttps://www.gnupg.org/documentation/manuals/gnupg/Ephemeral-home-directories.html ：

一時ディレクトリを作成し、ニーズを満たす構成を作成（またはコピー）し、環境変数GNUPGHOMEまたはオプション--homedirを使用してgpgにこのディレクトリを使用させます。 GPGMEは、コンテキストのエンジン情報を変更することにより、コンテキストごとにこれもサポートします。 次に、必要な操作を実行し、必要に応じてキーマテリアルをインポートおよびエクスポートします。 終了したら、ディレクトリを削除できます。 開始されたすべてのGnuPGバックエンドサービスはこれを検出してシャットダウンします

私のコンテナでこれをテストし、約束どおりにプロセスを自動的にクリーンアップしました。

@ petermax2テストスイートでHOMEが利用可能かどうかを確認できますか？

はい、 HOMEが利用可能です：

HOME = /tmp/elektra-test.3vLR4L

OK、テストスイートの何かがHOMEをtmpディレクトリにオーバーライドしています（これは良いことです）。 クリーンアップ中にそれがまだ利用可能な場合は、エージェントを停止するために削除する必要があります。 それは理想的な修正です。

GNUPGHOMEだけでは、 gpg-agentインスタンスが1つだけ生成されます。 GNUPGHOMEは、テストが開始される前に上書きされません。

GNUPGHOME設定すると、複数のテストの実行後に1つのgpg-agentが実行されます。

これが最も簡単な解決策だと思います。

ホームディレクトリを共有すると、テストを並行して実行できない場合があることに注意してください。
また、後でGNUPGHOMEを削除する必要があります（ログインしているユーザーの呼び出しに応答するpgp-agentが長引くことは望ましくありませんか？）。

また、ターゲットシステムがGNUPGHOMEでリレーするとどうなるか、既存のenvを保存し、テスト後に手動で復元する必要があります。

一歩下がって、これらのテストがテストサーバー環境だけでなくユーザーマシンにどのように影響するかを見ていただければ幸いです。

テストを並行して実行できない場合があります。

スクリプトを実行しました：

#!/bin/bash
mkdir /tmp/x
export GNUPGHOME=/tmp/x
for run in {1..1000000}
do
    ctest -R crypto_openssl &
done

問題なく。 GPGはロックなどを処理する必要があります。

ログインしたユーザーの呼び出しに長引くpgp-agentが応答することを望まないのですか？

これはgpg-agentが設計された方法です：ユーザーセッションが終了するまで永久に実行されます。 PIDをどこかに書き出すことはなく、終了するコマンドもありません。 SIGTERMにのみ反応します。

--serverオプションを使用して単体テスト内からfork gpg-agentしようとしたので、後でkillへのPIDがあります。 ただし、 gpg-agentは$GNUPGHOMEで必要なソケットを開かず、単体テストはエージェントの別のインスタンス（ --daemonモードで実行されている）を再度開きます。 また、 --serverモードのときにgpg-agentソケットを開く方法はありません（これをソースコードgpg-agent ）。

gpg-agentは制御が難しく、文書化もほとんどされていません。 gpg-agentのソースコードも読んでいました。 私たちのユースケースはカバーされていません。 唯一のオプションはSIGTERMです。

並列処理

お互いに影響を与えてはいけないgpg-agentを分離したいということをもっと考えていました。 つまり、エージェントaにテストaのキーのみを持たせ、エージェントbにテストbのキーを持たせます。 それが必要ない場合は、ハードコードされたtmpホームで問題ありません。

gpg-agentを殺す

この問題を最初に調査したとき、一時的なgpg-agentをシャットダウンするための予想される方法はそのgpgホームディレクトリを削除することであると述べたWebサイト（上記のリンク）に出くわしました。

したがって、GNUPGHOMEを/tmp/elektra_tests/gpgし、テストのクリーンアップ中にこのtmpディレクトリを削除すると、問題ないはずです。

したがって、GNUPGHOMEを/ tmp / elektra_tests / gpgに設定し、テストのクリーンアップ中にこのtmpディレクトリを削除すると問題ありません。

できます！ この修正をcryptoおよびfcryptテストケースに統合します。 ヒントありがとうございます！

私は実用的なプロトタイプを持っています。 PRは明日来ます。

＃2056で修正する必要があります。 それでも問題が解決しない場合は、再度開いてください。