gpg-agent каже, що агент існує, але gpg говорить, що агент не існує?

Я борюся з деякими проблемами під час створення gpg з bashвікном Debian 6.0.6. У мене є сценарій, який виконує пакет операцій і хоче переконатися, що gpg-агент доступний, перш ніж він намагається продовжити.

Оскільки 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не існує можливості запитати, чи доступний агент доступним сценарієм, наскільки він любить мовчки ігнорувати одержувачів з непридатними ключами та все ж повертати успіх, тому перед початком партії виявити цю проблему дуже важко. Я не хочу потрапляти на аналіз синтаксису gpg з i18n причин серед інших.

Ви можете відтворити це, переконавшись, що у вас не працює або GPG_AGENT_INFOвстановлено gpg-агент , потім в одному запущеному терміналі eval $(gpg-agent --daemon)та в іншому терміналі, що працює вище. Ви помітите, що gpg-агент каже, що він вже працює, але gpg не вдається підключитися до агента.

Ідеї?

ОНОВЛЕННЯ : 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, якщо це добре.

1. Ви можете перевірити код виходу gpg-connect-agent /bye
2. Ви можете перевірити, чи існує сокет, вказаний у $ GPG_AGENT_INFO. Цього має бути достатньо, але ви також можете перевірити за допомогою фюзера або lsof, чи є процес, вказаний у $ GPG_AGENT_INFO, тим, що відкрив сокет. І якщо ви хочете бути дуже вичерпними, ви також можете перевірити, чи / proc / $ PID / exe є посиланням на / usr / bin / gpg-agent (або що завгодно).

Основна версія запущеного агента gpg - 2. Вам слід посилатись на gpg2, а не gpg, як тут відповіли: /unix/231386/how-to-make-gpg-find-gpg-agent

Поки що найкращим способом подолання є наступний жахливий безлад:

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-агент дійсно працює. (Я ще не впевнений, як це взаємодіє з іншими реалізаціями gpg-агента, такими як агент GNOME). Якщо інформація про агента встановлена, але агент не працює, він не знає, як впоратися і здається.

Якщо інформація про агент не встановлена, він перевіряє, чи працює агент. Якщо це так, він шукає інформацію про оточення у кількох добре відомих місцях, і якщо не зможе його знайти, здається.

Якщо агент не працює, а інформація про агент не встановлена, він запускає агент, записує env-файл у приватне місце та продовжує.

Сказати, що я незадоволений цим жахливим, недоброзичливим і ненадійним злом, - це заниження.

Дуже дивно, що gpgінструмент безпеки / криптовалюти ігнорує аргументи та продовжує. --use-agentповинна бути фатальною помилкою, якщо агент не працює, принаймні, необов'язково, оскільки уточнення -rз недійсним одержувачем має бути помилкою, а не ігнорованою. Те, що gpgзнаходить свого агента іншим шляхом до gpg-agentкоманди, - дивовижне.

У моїй системі 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