Your message dated Sun, 05 Feb 2017 18:06:25 -0500
with message-id <[email protected]>
and subject line closing #642021 since gpg-agent is using the standard socket
now
has caused the Debian Bug report #642021,
regarding gnupg-agent: /etc/X11/Xsession.d/90gpg-agent does not recognize a
console/SSH gpg-agent
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
642021: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642021
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: gnupg-agent
Version: 2.0.18-1
Severity: important
File: /etc/X11/Xsession.d/90gpg-agent
Tags: patch
Affect: openssh-client
Hi there!
The gpg-agent manpage contains (twice) an example about sharing the same
running gpg-agent session with different shell invocations. This is
mostly useful if you login in the console or remotely via SSH.
However, /etc/X11/Xsession.d/90gpg-agent implements that example in a
different and buggy way.
1) I fully understand the need for a -$(hostname) suffix for the "PID"
file (see #312717), but I would add a note in a README.Debian file,
something like:
--8<---------------cut here---------------start------------->8---
gnupg-agent for Debian
----------------------
* Default environment file
When enable in gpg.conf (option "use-agent"), gpg-agent is
automatically started in a graphical session thanks to
/etc/X11/Xsession.d/90gpg-agent.
In this case, the default environment file is located at
"$GNUPGHOME/gpg-agent-info-$(hostname)" to account for NFS-mounted
home directories (see Debian bug #312717 for more information).
-- Luca Capello <[email protected]>, Sun, 18 Sep 2011 17:52:52 +0200
--8<---------------cut here---------------end--------------->8---
BTW, it is a bit unfortunate to have used "PID" instead of "ENV",
given that this file is not a PID file at all and the CLI option to
use it is called --write-ENV-file (emphasis is mine). Given that
this variable is used only locally, I can provide a patch to fix it.
2) where does $GNUPGHOME/options come from? I could not find any
reference to this file in the current gpg manpage, I would remove it.
3) the gpg-agent manpage contains the following statement:
DESCRIPTION
[fifht paragraph]
Note that by running gpg-agent without arguments you may test
whether an agent is already running; however such a test may
lead to a race condition, thus it is not suggested.
I still fail to understand why it is needed in line 8 (see #336480):
as far as I understand it any running gpg-agent should set the
GPG_AGENT_INFO environment variable, which means that if this
variable is empty something is wrong with the gpg-agent process.
This is a minor issue.
OTOH I see why it is needed in line 16, which is a bug in gpg-agent
itself: the PID file is not deleted once the gpg-agent exits, which
means that the same PID file is present at the next login.
However, even if the PID file exists, simply sourcing it is not
enough, because the environment variables are not available for other
processes. I tested this firstly logging into the console with a
snippet similar to /etc/X11/Xsession.d/90gpg-agent and then logging
into XDM:
=====
$ ps aux | grep -B 2 agent
root 8528 0.0 0.1 77708 2652 tty2 Ss 18:17 0:00 \
/bin/login --
luca 8556 0.1 0.4 18800 9572 tty2 S+ 18:17 0:00 \
-bash
luca 8614 0.0 0.0 18968 444 ? Ss 18:17 0:00 \
/usr/bin/gpg-agent --daemon --sh
--write-env-file=/home/luca/.gnupg/gpg-agent-info-gismo
--
luca 8723 0.0 0.0 21976 1228 ? S 18:18 0:00 \
/usr/bin/unclutter -idle 1 -root
luca 8726 0.0 0.1 29368 2236 ? S 18:18 0:00 \
/usr/bin/xbindkeys -f /home/luca/.xbindkeysrc
luca 8727 0.0 0.0 19316 848 ? Ss 18:18 0:00 \
/usr/bin/gpg-agent --daemon --sh
--write-env-file=/home/luca/.gnupg/gpg-agent-info-gismo \
/usr/bin/ck-launch-session \
/usr/bin/dbus-launch --exit-with-session /home/luca/.xsession
$ ls -l /tmp* | grep gpg
drwx------ 2 luca luca 60 Sep 18 18:18 gpg-91Daqi
drwx------ 2 luca luca 60 Sep 18 18:17 gpg-cuvChu
drwx------ 2 luca luca 60 Sep 18 18:18 gpg-eOvBEn
drwx------ 2 luca luca 60 Sep 18 18:17 gpg-nrcUfG
$ export | grep -e GPG -e SSH
declare -x GPG_AGENT_INFO="/tmp/gpg-91Daqi/S.gpg-agent:8727:1"
declare -x SSH_AGENT_PID="8727"
declare -x SSH_AUTH_SOCK="/tmp/gpg-eOvBEn/S.gpg-agent.ssh"
$ ls -l /home/luca/.gnupg/gpg-agent-info-gismo
-rw-r--r-- 1 luca luca 115 Sep 18 18:18 /home/luca/.gnupg/gpg-agent-info-gismo
=====
As explained in the gpg-agent manpage, at least GPG_AGENT_INFO and
SSH_AUTH_SOCK should be exported. However, given that when started
"normally" gpg-agent export all of the three variables, I do not
understand why the gpg-agent manpage suggests to export only the two
above. The patch is easy:
--8<---------------cut here---------------start------------->8---
--- 90gpg-agent.ORG
+++ 90gpg-agent
@@ -9,6 +9,9 @@
if [ -r "$PID_FILE" ]; then
. "$PID_FILE"
+ export GPG_AGENT_INFO
+ export SSH_AUTH_SOCK
+ export SSH_AGENT_PID
fi
# Invoking gpg-agent with no arguments exits successfully if the agent
--8<---------------cut here---------------end--------------->8---
Thx, bye,
Gismo / Luca
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.1.0-rc4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages gnupg-agent depends on:
ii libassuan0 2.0.2-1
ii libc6 2.13-21
ii libgcrypt11 1.5.0-3
ii libgpg-error0 1.10-1
ii libpth20 2.0.7-16
ii libreadline6 6.2-4
ii pinentry-curses [pinentry] 0.8.1-1
Versions of packages gnupg-agent recommends:
ii gnupg 1.4.11-3
ii gpgsm 2.0.18-1
gnupg-agent suggests no packages.
-- no debconf information
pgpWVurUK9cAt.pgp
Description: PGP signature
--- End Message ---
--- Begin Message ---
Version: 2.1.0-1
Since GnuPG on the 2.1.x branch uses the "standard socket" location, i
think #642021 is no longer relevant. I'm closing this bug report, but
feel free to reopen (or open a new one) if you think it's still a
concern.
--- End Message ---
