Control: severity 778657 normal Control: done 778657 2.0.26-4 Hi Brian--
Sorry to take a while to get back to you on this. I don't think these changes are appropriate for the /etc/X11/Xsession.d/90gpg-agent and i think some of your analysis of the (admittedly baroque) code is mistaken (see discussion below), so i'm closing this bug because i think there's nothing to do for it. If you think my analysis below is mistaken, please reopen the bug and explain what you think should happen next! On Tue 2015-02-17 19:40:45 -0500, Brian C. Duggan wrote: > The gpg-agent Xsession.d script looks as if it wants to test for an > existing, usable gpg-agent. It looks as if it is supposed to skip > starting a new one for the X session if it finds an existing gpg-agent > process. That's right. If an existing process provides gpg-agent (and indicates it with the $GPG_AGENT_INFO environment variable), the Xsession.d script should avoid starting up a new agent. > I wanted to use this functionality to run gpg-agent as a user service > under systemd as the sole gpg-agent process for all my sessions. I set > up and enabled the service. systemd starts all enabled user services > on the first user login. I logged in on a virtual console and verified > that gpg-agent was running and I could connect to it. Then I logged in > to an X session and noticed that X had still started its own > gpg-agent. We don't currently recommend running gpg-agent as a systemd user service, for a number of reasons. * gpg-agent is likely to change over to --use-standard-socket by default. This is probably incompatible with multiple systemd user sessions running concurrently. * gpg2 and related tools that need to talk to the agent will also soon start auto-launching the daemon when it is needed but not present. I can understand the desire to have all of this session-oriented stuff managed by a real distinct session manager, but that's not where gnupg is at right now. (btw, if you want to work on getting gpg-agent to function as a systemd service, i'd be keen to see that happen. But i think there may be some tricky issues with it, like the ones described above. Please come talk to us at [email protected] or on #debian-gnupg about it.) > The code that looks like it should check for gpg-agent is here: > > /etc/X11/Xsession.d/90gpg-agent: > 6: if grep -qs '^[[:space:]]*use-agent' "$GNUPGHOME/gpg.conf" > "$GNUPGHOME/options" && > 7: test -x $GPGAGENT && > 8: { test -z "$GPG_AGENT_INFO" || ! $GPGAGENT 2>/dev/null; }; then > > GPGAGENT=/usr/bin/gpg-agent > > When run without arguments, gpg-agent's exit status will be 0 if it > can connect to an existing gpg-agent process, a positive value if it > cannot. Regardless of exit status, gpg-agent run without arguments > writes all output to stderr. > > So, the second part of the expression in line 8 is alwys true. The > output of '$GPAGENT 2>/dev/null' is always an empty string because > gpg-agent sends all output to stderr. [ ! "" ] is true. but we're not in [ (test) here. the test invocation applies to: -z "$GPG_AGENT_INFO" then || is a shell conjunction which splits the test from the second half, which is just looking at the return value of an invocation of $GPGAGENT. > So, the entire expression on line 8 is always true. But in my testing, > I also couldn't configure X so that it passed environment variables to > the X session. I wrote a .xsession file like this: > > #!/bin/sh > export MYTESTVAR=test > eval startxfce4 > > and then added 'echo $MYTESTVAR > /tmp/mytestvar' to 90gpg-agent. But > the corresponding echo-to-file statement in 90gpg-agent never wrote > anything. Am I missing an obvious method of passing $GPG_AGENT_INFO to > 90gpg-agent? This would normally be done by an earlier stage of the Xsession.d directory, or by pam hooks that were triggered during gdm login. by the time your .xsession is invoked, the rest of Xsession.d/ has already been sourced. Lastly, i think ~/.gnupg/.gpg-agent-info is deprecated upstream, so changing the Xsession.d/ script to depend more heavily on it would be problematic, even if the rest of the analysis were correct. Let me know if you have any more questions. Regards, --dkg
signature.asc
Description: PGP signature
