$ grep extra-socket .gnupg/gpg-agent.conf extra-socket /home/teythoon/.gnupg/S.gpg-agent.extra $ gpgconf --list-dirs | grep extra-socket agent-extra-socket:/run/user/1000/gnupg/S.gpg-agent.extra $ ls /home/teythoon/.gnupg/S.gpg-agent.extra /run/user/1000/gnupg/S.gpg-agent.extra ls: cannot access '/run/user/1000/gnupg/S.gpg-agent.extra': No such file or directory /home/teythoon/.gnupg/S.gpg-agent.extra=
Description
Description
Details
Details
- Version
- 2.1.18-6
Event Timeline
Comment Actions
I think it only lists the wrong "extra socket path" when one is specified in gpg-agent.conf, right?
one way to resolve this would be to deprecate that option entirely, and just use the standard socket.
Comment Actions
Yes.
one way to resolve this would be to deprecate that option entirely, and just use the standard socket.
Well, the extra socket supports only a restricted subset of operations, and is thought to be used for forwarding to other hosts. I'd love to remove every one of the socket options, but changing these kind of aspects of gpg has proven to be very difficult.
Comment Actions
I didn't mean to remove the capability of having a restricted "extra-socket". I meant that we could remove (or deprecate) the capability of placing the restricted "extra-socket" at an arbitrary location. I agree with you that having the restricted "extra-socket" is an important capability that gpg shouldn't remove.
Comment Actions
We can't change that anymore. So the question is how and whether to fix it. Right now gpgconf --list-dirs has no need to ask gpg-agent for the actual socket and it would be a catch-22 anyway. Thus to fix this we need to parse the gpg-agent.conf in gpg.conf directly.
Or we document this bug for --extra-socket.