On 21 Sep 2015, [email protected] verbalised: > We are now in serious trouble -- gpg-agent cannot do anything, and half > the time it's wedged so hard only kill -9 will get rid of it.
A terrible, hacky workaround is to change *_SOCK_NAME in configure.ac to place all the sockets in a new subdirectory of .gnupg (I called it 'sockets') and then have the boot process populate a subdirectory of /run with per-user directories readable only by the local user and create the sockets directory as a symlink to that. I did this just to verify that my diagnosis was correct. It is: once the Unix-domain sockets are on a local filesystem, and deletion of one of them does not conflict with everyone else's instance, then the gpg-agent extra-socket setup and the whole dance with "ssh -o StreamLocalBindUnlink=yes -R $HOME/.gnupg/sockets/S.gpg-agent:$HOME/.gnupg/sockets/S.gpg-extra-agent" works as intended, even when $HOME is NFS-mounted. (And indeed, the --card-status I was using as a testcase reports 'Forbidden', indicating that the connection is being forwarded over the agent successfully.) But you *do* need to jump through these hoops first, to get the sockets onto a local filesystem even if the $GNUPGHOME is NFS-shared. This is probably more hoops than we should ask users to jump through... -- NULL && (void) _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
