So I have a 2.0 installation I'm trying to get up to 2.1, taking advantage of the opportunity given by sticking my GPG key on a smartcard and using it for SSH authentication.
Everything is going smoothly, the smartcard part is working fine, but unfortunately the fixed path used for the GPG agent in 2.1 is having catastrophically bad effects on agent forwarding when used in conjunction with an NFS-mounted $HOME. The old model was simple: SSH simply had to create a randomly named socket somewhere (under /tmp and only readable by the user, so as secure as these things get, and guaranteed to be on a single machine), point GPG at it, and forward all requests. This just worked. In GPG 2.1... well, obviously I want my $HOME/.gnupg to be NFS-mounted, so that no matter what machine in the cluster I am on they all see the same keyrings, trustdb etc. The dotlocking means that this should work fine even in the presence of simultaneous gnupg invocations on different machines, and indeed in 2.0 it did. But in 2.1... ... the problem is that the gnupg socket is an unvarying $GNUPG_HOME/S.gpg-agent, but you cannot bind() to a Unix-domain socket that already has an existing file associated with it in the filesystem. SSH has an option to hack around this -- StreamLocalBindUnlink -- but using it is disastrous if $GNUPG_HOME is NFS-shared, because the first time it kicks in on ssh, the socket is removed and recreated, and since the filesystem is shared this happens on *all* machines sharing the NFS mount, breaking the communication channel the real GPG agent is using to communicate! The underying problem here is that Unix-domain sockets with a fixed name and shared filesystems are simply not compatible concepts, because AF_UNIX bind() always creates a new file so any given socket can only be used in one machine in a cluster at once, even though AF_UNIX sockets are purely local. Because of this, gpg 2.1 *has* to grow back an option to allow its agent socket to be moved, either to a different path or to a machine-unique name (preferably the former, it's less messy), or gpg agent forwarding will forever be hopeless on machines with NFS-mounted $HOMEs. Or so it seems to me. At least, I've been trying for a day and a half and made no progress. (The --extra-socket option is still worthwhile to provide a forwarding target, because you *do* want to restrict what a remote machine can ask your agent to do. It's just not enough to make things work.) (this message not signed because, well, I'd be using my smartcard signing key, and my Emacs is on a different machine... so this bug stops me! :/ ) -- NULL && (void) _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
