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

[Daniel Kahn Gillmor]

On Mon 2017-12-18 20:01:02 +1100, gnupg at raf.org wrote:
> For most of my decryption use cases I can't use a
> pinentry program. Instead, I have to start gpg-agent in
> advance (despite what its manpage says) with
> --allow-preset-passphrase so that I can then use
> gpg-preset-passphrase so that when gpg is run later, it
> can decrypt unaided.

can you explain more about this use case?  it sounds to me like you
might prefer to just keep your secret keys without a passphrase in the
first place.

> I also discovered that I need to disable systemd's
> handling of gpg-agent (on debian9 with gpg-2.1.18) if I
> want to control when gpg-agent starts and stops and
> which options are passed to it. I know this is not
> recommended but I've had too much trouble in the past
> with systemd thinking that it knows when a "user" has
> "logged out" and then deciding to "clean up" causing me
> masses of grief that I just can't bring myself to trust
> it to know what it's doing.
>
> I've disabled systemd's handling of gpg-agent on the
> debian9 hosts with:
>
>   systemctl --global mask --now gpg-agent.service
>   systemctl --global mask --now gpg-agent.socket
>   systemctl --global mask --now gpg-agent-ssh.socket
>   systemctl --global mask --now gpg-agent-extra.socket
>   systemctl --global mask --now gpg-agent-browser.socket
>
> (from /usr/share/doc/gnupg-agent/README.Debian)
>
> I know someone on the internet has expressed
> unhappiness about people doing this and not being happy
> about supporting people who do it but please just pretend
> that it's a non-systemd system. Not everything is Linux
> after all. Gnupg should still work.

i might be "someone on the internet" :)

I can pretend it's a non-systemd system if you like -- that means you
simply don't have functional per-user session management, and it's now
on you to figure out session management yourself.  


Without going into detail on your many questions, it sounds to me like
your main concern has to do with pinentry not seeming well-matched to
the way that you connect to the machines you use, and the way you expect
user interaction to happen.

Let me ask you to zoom out a minute from the specific details you're
seeing and try to imagine what you *want* -- ideally, not just in terms
of what you've done in the past.

for example, do you really want to have keys stored on a remote machine,
or do you want them stored locally, with the goal of being able to *use*
them remotely?  do you want to be prompted to confirm the use of each
private key?  do you expect that confirmation to include a passphrase
entry?  how do you conceive of your adversary in this context?  are you
concerned about leaking private key material?  auditing access?  some
other constraints?

      --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20171218/e765c350/attachment-0001.sig>