Walczę z pewnymi problemami podczas pisania skryptu na gpg bash
na pudełku Debiana 6.0.6. Mam skrypt, który wykonuje wiele operacji i chce się upewnić, że gpg-agent jest dostępny, zanim spróbuje kontynuować.
Ponieważ gpg-agent nie podejmie żadnych działań i zwróci sukces, jeśli zostanie uruchomiony, gdy jest już uruchomiony, upewnienie się, że agent jest obecny, jest tak proste, jak:
eval $(gpg-agent --daemon)
gpg-agent
rozpocznie się lub zgłosi:
gpg-agent[21927]: a gpg-agent is already running - not starting a new one
i zwraca 0 (sukces), jeśli już działa.
Problem powstaje, gdy agent jest już uruchomiony w innej sesji. gpg-agent
mówi, że już działa ... ale gpg
sam twierdzi, że jest niedostępny.
$ 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
To sprawia, że jestem sfrustrowany i zdezorientowany. Wygląda na gpg-agent
to, że wykrywa agenta w inny sposób, aby samemu sobie radzić z gpg. Co gorsza, gpg
nie można zapytać, czy agent jest dostępny w formie skryptowej, ponieważ lubi cicho ignorować odbiorców za pomocą bezużytecznych kluczy i nadal zwracać sukces, więc bardzo trudno jest wykryć ten problem przed rozpoczęciem partii. Nie chcę wchodzić w parsowanie wyników gpg, między innymi z powodów i18n.
Możesz to odtworzyć, upewniając się, że nie masz uruchomionego lub GPG_AGENT_INFO
skonfigurowanego agenta gpg , a następnie w jednym terminalu uruchomionym eval $(gpg-agent --daemon)
i w innym terminalu uruchomionym powyżej. Zauważysz, że gpg-agent mówi, że już działa, ale gpg nie łączy się z agentem.
Pomysły?
AKTUALIZACJA : gpg-agent
wykrywa innego agenta, szukając pliku gniazda w znanej lokalizacji i pisząc do niego w celu przetestowania żywotności, według tego 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
podczas gdy GnuPG wydaje się patrzeć tylko na środowisko, ignorując dobrze znaną lokalizację gniazda. W 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 */
}
Tak naprawdę nie chcę zabijać agenta, aby upewnić się, że mogę go uruchomić ponownie, i nie ma standardowego miejsca, w którym agent użytkownika mógłby zapisać plik środowiska. Co gorsza, nie mogę nawet przetestować obecności GPG_AGENT_INFO
w środowisku, ponieważ może to odnosić się do przestarzałego (martwego) agenta, który został zastąpiony ... i nie może gpg
też gpg-agent
zapewnić opcji wiersza polecenia do pingowania agenta i zwrócenia wartości true, jeśli jest to ok.
Odpowiedzi:
gpg-connect-agent /bye
źródło
gpg
jak robi to samo, więc może się powieść, gdy gpg następnie nie połączy się z agentem. To samo dotyczy (2), ponieważ agent może być uruchomiony, ale GPG_AGENT_INFO nie jest ustawiony w bieżącej sesji i nie ma widocznego sposobu, aby poprosić ogpg-agent
polecenieGPG_AGENT_INFO
już działającego agenta.Główną wersją działającego agenta gpg jest 2. Powinieneś wywołać gpg2 zamiast gpg, zgodnie z odpowiedzią tutaj: /unix/231386/how-to-make-gpg-find-gpg-agent
źródło
Jak dotąd najlepszym obejściem jest następujący ohydny bałagan:
Spowoduje to sprawdzenie
GPG_AGENT_INFO
w środowisku i jeśli jest ustawione, upewnij się, że gpg-agent faktycznie działa. (Nie jestem jeszcze pewien, jak to współdziała z innymi implementacjami gpg-agent, takimi jak agent GNOME). Jeśli informacje o agencie są ustawione, ale agent nie działa, nie wie, jak sobie z tym poradzić i się poddaje.Jeśli informacje o agencie nie są ustawione, sprawdza, czy agent jest uruchomiony. Jeśli tak, szuka informacji o env w kilku dobrze znanych lokalizacjach, a jeśli nie uda się jej znaleźć, poddaje się.
Jeśli agent nie działa, a informacje o agencie nie są ustawione, uruchamia agenta, zapisuje plik env w prywatnej lokalizacji i kontynuuje.
Stwierdzenie, że jestem niezadowolony z tego okropnego, wrogiego i niewiarygodnego włamania, jest niedopowiedzeniem.
To bardzo zaskakujące, że
gpg
narzędzie bezpieczeństwa / szyfrowania zignoruje argumenty i przejdzie dalej.--use-agent
powinien być błędem krytycznym, jeśli agent nie jest uruchomiony, przynajmniej opcjonalnie, ponieważ określenie-r
z niepoprawnym odbiorcą powinno być błędem, a nie ignorowane. Fakt, żegpg
jego agent różni się odgpg-agent
polecenia, jest oszałamiający.źródło
pgrep gpg-agent
), możesz to zrobić, aby znaleźć gniazdo:lsof -n -p $PID | grep S.gpg-agent$ | awk '{print $NF}'
gpg-agent
nie powiedzgnome-keyring-daemon
w pracy. bo to nie było już wystarczająco okropne: S. Dziwi mnie, że to wszystko jest tak niespójne.! test -v GPG_AGENT_INFO
nie działa w systemie Mac OS X. Zamiast tego musisz użyć czegoś takiego[ -z ${GPG_AGENT_INFO+x} ]
.W moim systemie Ubuntu
gpg-agent
jest skonfigurowany do zapisywania pliku środowiska~/.gnupg/gpg-agent-info-$(hostname)
( do czego służy/etc/X11/Xsession.d/90gpg-agent
). Jeśli Twój system tego nie robi, możesz zmodyfikować sposób, w jaki agent uruchamia się, aby zapisać plik środowiska w dobrze znanej lokalizacji, którą można później uzyskać. Na przykład:źródło
gpg-agent[2333]: WARNING: "--write-env-file" is an obsolete option - it has no effect