Upgrading from gpg1 to gpg2: lots of trouble, need help

[Daniel Kahn Gillmor]

On Thu 2017-12-21 16:19:00 +1100, raf wrote:
> Sorry, I thought I already did. The 4th point above does not
> work. When the public-facing host connects via ssh to the
> key management host, and runs gpg, instead of it successully
> connecting to the existing gpg-agent process that I started
> minutes earlier, it starts a new gpg-agent process which
> doesn't know the passphrase and so the decryption fails.
>
> Here are the gpg-agent processes after I start the first gpg-agent
> process and preset the passphrase:
>
>   /usr/bin/gpg-agent --homedir /etc/thing/.gnupg --allow-preset-passphrase \
>     --default-cache-ttl 3600 --max-cache-ttl 3600 --daemon -- /bin/bash --login
>
> Here are the gpg-agent processes after an inoming ssh connection that
> attempts to use gpg:
>
>   /usr/bin/gpg-agent --homedir /etc/thing/.gnupg --allow-preset-passphrase \
>     --default-cache-ttl 3600 --max-cache-ttl 3600 --daemon -- /bin/bash --login
>   gpg-agent --homedir /etc/thing/.gnupg --use-standard-socket --daemon
>
> That second gpg-agent process should not exist. The gpg
> process that caused it to be started should have connected
> to the existing gpg-agent process. The sockets for it
> existed but perhaps there was some reason why it didn't use
> them.
>
> There must be some reason why gpg thinks it needs to start
> gpg-agent. Perhaps it's because it's a different "user
> session". They are from two different ssh connections after
> all.

this is the part that i'm unable to reproduce.

Are both of these processes running as the same user account?

does something at some point destroy or mask the standard socket created
by the first process, so that a new gpg invocation decides to start up a
new instance of gpg-agent?

if your old session was being terminated, then you'd expect the first
agent to actually disappear.  that's not happening.

and neither of these agents is beign launched by systemd, because if it
were it would have a --supervised .

> But when I su to the user in question, I get:
>
>   > systemctl --user is-enabled gpg-agent.service gpg-agent.socket gpg-agent-ssh.socket gpg-agent-extra.socket gpg-agent-browser.socket
>   Failed to connect to bus: No such file or directory
>
> But it still reports as enabled with --global.
> Maybe that's enough. I don't know.

are you su'ing with a login shell (i.e. with - or -l or --login), or
not?

> I am completely failing to understand what's going on here. :-)
> Is systemd handling the sockets or not? There's no /run/user
> directory for this user so probably not. Maybe I don't
> understand --user and --global or systemd in general.

why is there no /run/user for this user?  if you're running a modern
version of systemd, and your user has actually started a session, there
should be a /run/user created automatically.

       --dkg