web-dev-qa-db-ja.com

gpg-agentはエージェントが存在すると言いますが、gpgはエージェントが存在しないと言いますか？

Debian 6.0.6ボックスでbashを使用してgpgをスクリプト化しているときに、いくつかの問題で苦労しています。一連の操作を行うスクリプトがあり、続行する前にgpg-agentが使用可能であることを確認したい。

Gpg-agentは、すでに実行されているときに起動された場合、何のアクションも実行せず成功を返すため、エージェントが存在することを確認するのは次のように簡単です。

eval $(gpg-agent --daemon)

gpg-agent開始、またはレポートします：

gpg-agent[21927]: a gpg-agent is already running - not starting a new one

すでに実行されている場合は0（成功）を返します。

この問題は、エージェントがすでに別のセッションで実行されている場合に発生します。 gpg-agentは、それがすでに実行されていると言います...しかし、gpgその自己は、それが利用できないと主張します。

$ gpg-agent --version
gpg-agent (GnuPG) 2.0.19
libgcrypt 1.5.0
$ gpg --version
gpg (GnuPG) 1.4.13

$ eval $(gpg-agent --daemon)
gpg-agent[21927]: a gpg-agent is already running - not starting a new one
$ gpg -d demo-file.asc
gpg: gpg-agent is not available in this session

これは私を苛立たせ、混乱させます。 gpg-agentが自身をgpgする別の方法でエージェントを検出しているようです。さらに悪いことに、gpgは、エージェントがスクリプトで利用できるかどうかを尋ねる方法を提供していません。使用できないキーを持つ受信者を黙って無視し、それでも成功を返すため、この問題を検出してから開始するのは非常に困難です。バッチ。とりわけi18nの理由でgpgの出力を解析したくありません。

これを再現するには、gpg-agentが実行されていないか、GPG_AGENT_INFOが設定されていることを確認してから、1つのターミナルでeval $(gpg-agent --daemon)およびinanotherterminal上記を実行しています。 gpg-agentはすでに実行されていると表示されますが、gpgはエージェントへの接続に失敗します。

アイデア？

[〜＃〜] update [〜＃〜]：gpg-agentは、既知の場所でソケットファイルを検索し、そのファイルに書き込みを行うことで、別のエージェントを検出し、このstrace：

socket(PF_FILE, SOCK_STREAM, 0)         = 5
connect(5, {sa_family=AF_FILE, Sun_path="/home/craig/.gnupg/S.gpg-agent"}, 32) = 0
fcntl(5, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(5, F_GETFL)                       = 0x2 (flags O_RDWR)
select(6, [5], NULL, NULL, {0, 0})      = 1 (in [5], left {0, 0})
read(5, "OK Pleased to meet you, process "..., 1002) = 38
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f41a3e61000
write(2, "gpg-agent: gpg-agent running and"..., 43gpg-agent: gpg-agent running and available
) = 43

gnuPGは環境のみを調べているように見え、既知のソケットの場所は無視されます。 common/simple-pwquery.c内：

/* Try to open a connection to the agent, send all options and return
   the file descriptor for the connection.  Return -1 in case of
   error. */
static int
agent_open (int *rfd)
{
  int rc;
  int fd;
  char *infostr, *p;
  struct sockaddr_un client_addr;
  size_t len;
  int prot;
  char line[200];
  int nread;

  *rfd = -1;
  infostr = getenv ( "GPG_AGENT_INFO" );
  if ( !infostr || !*infostr )
    infostr = default_gpg_agent_info;
  if ( !infostr || !*infostr )
    {
#ifdef SPWQ_USE_LOGGING
      log_error (_("gpg-agent is not available in this session\n"));
#endif
      return SPWQ_NO_AGENT;
    }
    /* blah blah blah truncated blah */
}

エージェントを強制的に再起動できるようにするためにエージェントを強制終了したくはありません。ユーザーのエージェントが環境ファイルを書き込む標準的な場所はありません。さらに悪いことに、環境にGPG_AGENT_INFOが存在するかどうかをテストすることもできません。これは、置き換えられた古い（デッド）エージェントを参照する可能性があり、gpgもgpg-agentもコマンドラインオプションを提供しないためです。エージェントにpingし、問題がなければtrueを返します。

scriptingshellgpg
9
Craig Ringer
  1. gpg-connect-agent /byeの終了コードを確認できます
  2. $ GPG_AGENT_INFOで指定されたソケットが存在するかどうかを確認できます。それで十分ですが、fuserまたはlsofを使用して、$ GPG_AGENT_INFOで指定されたプロセスがソケットを開いたプロセスであるかどうかを確認することもできます。また、本当に徹底的にしたい場合は、/ proc/$ PID/exeが/ usr/bin/gpg-agent（またはその他）へのリンクであるかどうかを確認することもできます。
6
Hauke Laging

実行中のgpgエージェントのメジャーバージョンは2です。ここで回答されているように、gpgではなくgpg2を呼び出す必要があります。 https://unix.stackexchange.com/questions/231386/how-to-make-gpg-find-gpg-エージェント

4
Hermann

これまでのところ、私が持っている最善の回避策は次の恐ろしい混乱です：

if ! test -v GPG_AGENT_INFO; then
    if gpg-agent 2>/dev/null; then
        if test -e /tmp/.gpg-agent-$USER/env; then
            . /tmp/.gpg-agent-$USER/env
        Elif test -e ~/.gpg-agent-info; then
            . ~/.gpg-agent-info
        else
            echo 'A gpg agent is running, but we cannot find its socket info because'
            echo 'the GPG_AGENT_INFO env var is not set and gpg agent info has not been'
            echo 'written to any expected location. Cannot continue. Please report this'
            echo 'issue for investigation.'
            exit 5
        fi
    else
        mkdir /tmp/.gpg-agent-$USER
        chmod 700 /tmp/.gpg-agent-$USER
        gpg-agent --daemon --write-env-file /tmp/.gpg-agent-$USER/env
        . /tmp/.gpg-agent-$USER/env
    fi
    # The env file doesn't include an export statement
    export GPG_AGENT_INFO
else
    if ! gpg-agent 2>/dev/null; then
        echo 'GPG_AGENT_INFO is set, but cannot connect to the agent.'
        echo 'Unsure how to proceed, so aborting execution. Please report this'
        echo 'issue for investigation.'
        exit 5
    fi
fi

これにより、環境でGPG_AGENT_INFOがチェックされ、設定されている場合は、gpg-agentが実際に実行されていることを確認します。 （これがGNOMEのエージェントのような他のgpg-agent実装とどのように相互作用するかはまだわかりません）。エージェント情報が設定されているがエージェントが実行されていない場合、エージェントは対処方法を知らず、あきらめます。

エージェント情報が設定されていない場合は、エージェントが実行されているかどうかを確認します。ある場合は、よく知られているいくつかの場所でenv情報を探し、見つからない場合はあきらめます。

エージェントが実行されておらず、エージェント情報が設定されていない場合は、エージェントを起動し、envファイルをプライベートな場所に書き込んでから続行します。

私がこの恐ろしく、ユーザーに敵対的で信頼できないハッキングに不満を持っていると言うのは控えめな表現です。

セキュリティ/暗号化ツールであるgpgが引数を無視して続行することは非常に驚くべきことです。エージェントが実行されていない場合、--use-agentは致命的なエラーになるはずです。少なくともオプションとして、無効な受信者で-rを指定すると、無視されるのではなくエラーになるはずです。 gpgがそのエージェントをgpg-agentコマンドとは異なる方法で見つけるという事実は当惑しています。

3
Craig Ringer

私のUbuntuシステムでは、_gpg-agent_は環境ファイルを~/.gnupg/gpg-agent-info-$(hostname)に書き込むように構成されています（これは_/etc/X11/Xsession.d/90gpg-agent_によって行われます）。システムがこれを行わない場合は、エージェントを起動して、後で入手できる既知の場所に環境ファイルを書き込む方法を変更できます。例えば：

_$ gpg-agent --daemon --write-env-file="$HOME/.gnupg/gpg-agent-info"
$ source ~/.gnupg/gpg-agent-info
_
2
mgorven