Я борюсь с некоторыми проблемами при написании сценариев для gpg bash
на Debian 6.0.6. У меня есть скрипт, который выполняет пакет операций и хочет убедиться, что 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 по ряду причин.
Вы можете воспроизвести это, гарантируя , что вы не имеете GPG-агент , работающий или GPG_AGENT_INFO
установлены, то в одном терминале управления eval $(gpg-agent --daemon)
и в другом терминале работает выше. Вы заметите, что gpg-agent говорит, что он уже запущен, но 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
предоставить параметр командной строки для проверки связи с агентом и возврата true, если он Хорошо.
Ответы:
gpg-connect-agent /bye
источник
gpg
сам, поэтому он может преуспеть, если gpg впоследствии не сможет подключиться к агенту. То же самое верно для (2) в том, что агент может работать, но GPG_AGENT_INFO не установлен в текущем сеансе, и нет очевидного способа запроситьgpg-agent
команду дляGPG_AGENT_INFO
уже работающего агента.Основная версия запущенного агента gpg - 2. Вы должны вызвать gpg2, а не gpg, как ответили здесь: /unix/231386/how-to-make-gpg-find-gpg-agent
источник
На данный момент лучший обходной путь, который у меня есть, - это следующий отвратительный беспорядок:
Это проверит наличие
GPG_AGENT_INFO
в среде и, если оно установлено, убедитесь, что gpg-agent действительно запущен. (Я еще не уверен, как это взаимодействует с другими реализациями gpg-agent, такими как агент GNOME). Если информация об агенте установлена, но агент не запущен, он не знает, как справиться, и сдается.Если информация об агенте не установлена, он проверяет, работает ли агент. Если это так, он ищет информацию env в нескольких известных местах и, если ему не удается ее найти, сдается.
Если агент не запущен и информация об агенте не установлена, он запускает агент, записывает файл env в приватное местоположение и продолжает работу.
Сказать, что я недоволен этим ужасным, враждебным к пользователю и ненадежным хакером, - преуменьшение.
Очень удивительно, что
gpg
инструмент безопасности / шифрования игнорирует аргументы и продолжает работу.--use-agent
должна быть фатальной ошибкой, если агент не запущен, по крайней мере, опционально, так как указание-r
с недопустимым получателем должно быть ошибкой, а не игнорироваться. Тот факт, чтоgpg
агент находит другой путь кgpg-agent
команде, вызывает недоумение.источник
pgrep gpg-agent
), тогда ypu может сделать это, чтобы найти сокет:lsof -n -p $PID | grep S.gpg-agent$ | awk '{print $NF}'
gpg-agent
не сказатьgnome-keyring-daemon
на работе. потому что это не было уже достаточно ужасно: S. Я поражен, что это все такой противоречивый беспорядок.! test -v GPG_AGENT_INFO
не работает на Mac OS X. Вам нужно будет использовать что-то вроде[ -z ${GPG_AGENT_INFO+x} ]
этого.В моей системе Ubuntu
gpg-agent
сконфигурирована запись файла его окружения~/.gnupg/gpg-agent-info-$(hostname)
(что сделано/etc/X11/Xsession.d/90gpg-agent
). Если ваша система этого не делает, вы можете изменить способ запуска агента для записи файла среды в хорошо известном месте, которое впоследствии можно будет найти. Например:источник
gpg-agent[2333]: WARNING: "--write-env-file" is an obsolete option - it has no effect