For apps designed to work with pre 2.1 versions of gnupg that expect a gpg-agent, there needs to be a GPG_AGENT_INFO environment variable set in order to work correctly. (In my case kde-apps/kgpg:4 complains that gpg-agent isn't running even though it is, but there may be others) I worked around it by setting GPG_AGENT_INFO='~/.gnupg/S.gpg-agent' within /etc/env.d/30gnupg but I'm not sure that is best practice or not. I'm using a systemd user service to start gpg-agent so that it starts regardless of the session type, so setting it in /etc/env.d is a desktop-manager agnostic solution to setting the environment variable rather than using something like ~/.kde/env/*.sh or /etc/kde/startup/agent-startup.sh. Reproducible: Always
gpg-agent should be executed within the context of the user. GPG_AGENT_INFO is to be set by the user taken out of the output of gpg-agent.
(In reply to Alon Bar-Lev from comment #1) > gpg-agent should be executed within the context of the user. Yes... Nothing has changed here. > GPG_AGENT_INFO is to be set by the user taken out of the output of gpg-agent. I have no clue what you're getting at. I have never seen any STOUT/STERR output from gpg-agent to specify the socket location. With version 2,1 the socket location cannot be changed. From the man page: --use-standard-socket --no-use-standard-socket --use-standard-socket-p Since GnuPG 2.1 the standard socket is always used. These options have no more effect.
(In reply to Reuben Martin from comment #2) > (In reply to Alon Bar-Lev from comment #1) > > gpg-agent should be executed within the context of the user. > > Yes... Nothing has changed here. > > > > GPG_AGENT_INFO is to be set by the user taken out of the output of gpg-agent. > > I have no clue what you're getting at. I have never seen any STOUT/STERR > output from gpg-agent to specify the socket location. With version 2,1 the > socket location cannot be changed. From the man page: > It is part of the output for <2.1 in eval output for --daemon, you are correct in that for 2.1 it is standard socket which is fixed name in gnupg homedir in question (so it is changed depending on the location of the homedir, it isnt a fixed location as such). Additionally it is possible to use socket redirection, which is useful e.g. for NFS /home mounts that doesnt support sockets. That'd require a text file in its place with %Assuan% socket= informations to specify the location (e.g. in /var/run, exported variables are supported using ${VAR} syntax) In any case, this seems to be an issue with applications using gnupg more than anything else, and as such they should be updated.
