web-dev-qa-db-ja.com

gpg-agentがスマートカードのピンを保存し続ける

今日、私は、enigmailがスマートカードのPINを要求せずにメッセージを復号化していることを発見しました。それは一度だけ尋ねて、それから全く尋ねません。

これは私のgpg-agent.confです。

default-cache-ttl 0
max-cache-ttl 0
no-allow-external-cache
ignore-cache-for-signing

scdaemon.conf：

card-timeout 0
deny-admin

gpg.confが空です

gpg（GnuPG）2.1.16

libgcrypt 1.7.3-beta

Gnomeキーリングが停止します。ここで何が欠けていますか？

gnupgsmartcardenigmail
5
Stanimir Stoyanov

私はこれを自分で調べてきました。 PINを入力するように求められます。スマートカード（この場合はユビキー）に署名/暗号化/認証操作を要求するたびに、この動作を有効にして署名することができますforcesigからgpg2 --card-editを有効にすることにより（ GnuPGのドキュメント を参照）：

forcesig   toggle the signature force PIN flag

暗号化および認証操作には使用できません。

GnuPGメーリングリストのこの投稿 Werner Koch氏自身は、スマートカード自体がPINをキャッシュしていることを示唆しているようです。

私はこれをさらに調査し（おそらくGnuPGメーリングリストにメールを送信します）、さらに情報が見つかったらこの回答を更新します。

8
Justin

私が見つけた簡単な回避策は、X秒ごとにgpg-agentをリロードするバックグラウンドでbashスクリプトを実行することです。具体的には、これを~/.bashrcに追加します。

while true; do gpgconf --kill gpg-agent; sleep X; done &

xは、ピンを保存する期間を秒単位で示します。このスクリプトは他のすべてのgpg関連プロセスも強制終了することに注意してください。そのため、gpgを主にpinentryプロセスに使用する場合、これは簡単な修正にすぎません。

これはバックグラウンドで実行されますが、jobsコマンドを使用してアクセスでき、killコマンドを使用して同様に停止できます。

0
user3037237

私の研究に基づくcard-timeoutはダミーパラメータであり、スマートカードピンのキャッシュに時間制限を強制することを意図したものではありません。

このバグレポート からの興味深い引用。

状況を説明させてください。

Scdaemonのマニュアルでは、指定された値によってscdaemonがスマートカードの電源を切るので説明されています。ただし、説明どおりに実装されたことはありません。

2.0では、DISCONNECTコマンドを許可するためにscdaemonを制御する変数でした。 2.1では、scdaemonが改善され、常にDISCONNECTコマンドを使用できるようになりました。

したがって、この変数は2.1では影響しません。

そして

これは何年もダミーのオプションでした（GnuPG 2.1以降）。参考までに、ここに詳細を記述します。

これらのバグレポーターが期待したとおりに機能しなかった（タイムアウトによってscdaemonからカードへのアクセスを直接制御した）ため、DISCONNECTコマンドの動作が変更されただけでした。ユーザーはいずれにしてもDISCONNECTコマンドを発行する必要があり、このオプションはDISCONNECTの実行方法を変更する可能性があります。 <-これは2.0です。

2.1以降、このオプションに関係なく、DISCONNECTコマンドは常に適切に機能します。

0
Cybernaut