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

[gnupg at raf.org]

Daniel Kahn Gillmor wrote:

> On Sun 2018-01-07 23:23:16 +1100, gnupg at raf.org wrote:
> > For the actual decryption, I'm using sudo. From the original
> > post, the command to set things up contains something like:
> >
> >   /usr/bin/screen -- \
> >   /usr/bin/sudo -u thing --set-home -- \
> >   /usr/bin/gpg-agent --homedir /etc/thing/.gnupg \
> >     --allow-preset-passphrase \
> > 	--default-cache-ttl 3600 \
> > 	--max-cache-ttl 3600 \
> > 	--daemon $gpg_agent_info -- \
> >   /bin/bash --login
> 
> this is deliberately launching a second agent, outside of the basic
> supervision that should already be in place.

No. It's starting the *first* agent. Remember, I had disabled
systemd's handling of gpg-agent so there is no supervising
gpg-agent process started by systemd.

When I showed the two gpg-agent processes that existed after the
incoming ssh connection ran gpg, they were the only two
gpg-agent processes owned by the 'thing' user. There was no
supervising one or I would have shown that one as well.

The problem is that the subsequent incoming ssh connection runs
gpg and that gpg process starts a second gpg-agent process
(which has no knowledge of the passphrase) rather than
connecting to this first gpg-agent process (which does have
knowledge of the passphrase - at least it does until the new
gpg-agent is started possibly because it took over the sockets
that were created by the first gpg-agent process).

> If you want to use the standard system agent, please do not launch a
> separate agent.

As I stated some time ago, I don't want to use the "standard
system agent" because I don't trust systemd to know when it's ok
to remove resources. I have had too much trouble caused by
systemd concluding that it was time to remove crucial resources
to be able trust it with anything that I need to rely on.

> This should be as simple as:
> 
>   screen -- sudo -u thing --login
> 
> or, if you're doing this as root already, then you don't need sudo at
> all, and it could just be:
>
>   screen -- su - testuser

It's not run as root.

> If this is run from cron, it will spawn a new session, and that session
> will have a systemd session manager capable of spawning gpg-agent as
> needed.

It's not run from cron. It wouldn't make sense to run it from cron.

> unfortunately, it will not spawn a new session if run from an existing
> session, see the discussion at
> https://github.com/systemd/systemd/issues/7451 .
> 
> if you want to manually start a new session for a new user from within
> an existing session on a machine managed by systemd, apparently
> machinectl may be the way to go, but i haven't explored that in full.

That must explain why systemd didn't create a /var/run
subdirectory for the 'thing' user during the sudo process (when
I re-enabled systemd's handling of gpg-agent).

But machinectl seems to be for containers. I'd rather not go
there since it might not be right since I'm not using
containers. It seems like a hack.

I think this is just another argument/example to support my
preference for avoiding the additional complexity of systemd
here and just using gnupg by itself.

> hope this helps,
> 
>         --dkg

Thanks. I appreciate the effort and research but it doesn't
really help. It doesn't address the issue of the incoming ssh
connection's gpg process starting up a new gpg-agent process
rather than connecting to the existing one.

But don't worry. I'm sure I've wasted enough of your time. When
I get time, I'll debug what's happening and either realise what
needs to be done or work around it somehow.

Thanks,
raf