[SOLVED]GPG no longer supports --no-use-standard-socket?

codemac · 2014-11-25 20:37:08

I've used an SD card for where I store my gnupghome for a long time. I have delegated subkeys and all the configuration for them there. It's mounted to /mnt/keys on vfat. These cards use a FAT file system as I use these keys on multiple operating systems.

GPG with release 2.1 has removed the 'standard socket' options, which means now if your gnupg home is on any file system that can't create socket files (see: FAT), gpg-agent can no longer run. Ironically, this is also the release that *removes* all support for running gpg without an agent!

I'm disappointed this was not considered news for arch, I even wrote a small silly wrapper just for forcing me to read front page stories! (http://github.com/codemac/yosumiru)

The GPG news page had the following:

With GnuPG 2.1 the need of GPG_AGENT_INFO has been completely removed and the variable is ignored. Instead a fixed Unix domain socket named S.gpg-agent in the GnuPG home directory (by default ~/.gnupg) is used. The agent is also started on demand by all tools requiring services from the agent.

Any thoughts on how I can keep my gnupg on a FAT filesystem and still run the agent? I'm feeling pretty hosed right now, and am pretty confused why this feature was removed from gpg agent, as this would be as simple as keeping the old functionality, but maybe forcing the --no-use-standard-socket option to be in gpg.conf

Last edited by codemac (2014-12-02 18:43:06)

codemac · 2014-11-25 20:46:01

Note there was a patch someone provided about passing in a file descriptor (or some *non* $GNUPGHOME location) and it was a very terse and untechnical discussion.

http://lists.gnupg.org/pipermail/gnupg- … 29092.html

This is really depressing.

Last edited by codemac (2014-11-25 20:47:42)

codemac · 2014-11-25 20:53:48

http://lists.gnupg.org/pipermail/gnupg- … 28432.html:

No, gpg since 2.1 (i.e. git master) uses the socket S.gpg-agent in the
GNUPGHOME directory by default. Older versions used a random socket and
conveyed it via an envvar. The new system is much easier and on Windows
on use for many years. The only drawback is that it won't work on
certain remote file systems - if that ever turns out to be a problem we
will find a solution. With 2.0 you may also use the fixed socket name
approach by putting "use-standard-socket" into gpg-agent.conf or a
similar configure option. My latest fix to start it correctly is not
in 2.0; could be backported, though

I have found no references to any solutions found since April. Thinking I'll have to hack something like the --agent-fd patch thing and provide a --socket-file option that is just somewhere else on a fs that does support sockets.

codemac · 2014-11-25 21:03:08

For those following along with the drama:

; git log -1 9c380384dafb213334f8834178c5ceb0bf33db6e
commit 9c380384dafb213334f8834178c5ceb0bf33db6e
Author: Werner Koch <wk@gnupg.org>
Date:   Fri Oct 3 11:58:58 2014 +0200

    Remove support for the GPG_AGENT_INFO envvar.
    
    * agent/agent.h (opt): Remove field use_standard_socket.
    * agent/command.c (cmd_killagent): Always allow killing.
    * agent/gpg-agent.c (main): Turn --{no,}use-standard-socket and
    --write-env-file into dummy options.  Always return true for
    --use-standard-socket-p. Do not print the GPG_AGENT_INFO envvar
    setting or set that envvar.
    (create_socket_name): Simplify by removing non standard socket
    support.
    (check_for_running_agent): Ditto.
    * common/asshelp.c (start_new_gpg_agent): Remove GPG_AGENT_INFO use.
    * common/simple-pwquery.c (agent_open): Ditto.
    * configure.ac (GPG_AGENT_INFO_NAME): Remove.
    * g10/server.c (gpg_server): Do not print the AgentInfo comment.
    * g13/server.c (g13_server): Ditto.
    * sm/server.c (gpgsm_server): Ditto.
    * tools/gpgconf.c (main): Simplify by removing non standard socket
    support.
    --
    
    The [intended] fix to allow using a different socket than the one in the
    gnupg home directory is to change Libassuan to check whether the
    socket files exists as a [regular] file with a special keyword to
    redirect to another socket file name.

Time to get hacking on libassuan...

Leonid.I · 2014-11-25 21:22:49

codemac wrote:

I've used an SD card for where I store my gnupghome for a long time. I have delegated subkeys and all the configuration for them there. It's mounted to /mnt/keys on vfat. These cards use a FAT file system as I use these keys on multiple operating systems.

That's exactly what I used to do as well: mount a USB key read-only and run gpg --homedir /path/to/usb.

codemac wrote:

GPG with release 2.1 has removed the 'standard socket' options, which means now if your gnupg home is on any file system that can't create socket files (see: FAT), gpg-agent can no longer run. Ironically, this is also the release that *removes* all support for running gpg without an agent!
I'm disappointed this was not considered news for arch, I even wrote a small silly wrapper just for forcing me to read front page stories! (http://github.com/codemac/yosumiru)
The GPG news page had the following:
With GnuPG 2.1 the need of GPG_AGENT_INFO has been completely removed and the variable is ignored. Instead a fixed Unix domain socket named S.gpg-agent in the GnuPG home directory (by default ~/.gnupg) is used. The agent is also started on demand by all tools requiring services from the agent.
Any thoughts on how I can keep my gnupg on a FAT filesystem and still run the agent? I'm feeling pretty hosed right now, and am pretty confused why this feature was removed from gpg agent, as this would be as simple as keeping the old functionality, but maybe forcing the --no-use-standard-socket option to be in gpg.conf

I don't understand why you insist on using --no-use-standard-socket...

Some background: traditionally gpg-agent is started by a DE (e.g. xfce4-session starts it). This is useful because gpg-agent also manages ssh keys. However, this is not required anymore because agents are started on-demand and multiple agents can run concurrently.

Now, if you didn't have a vFAT FS, all is good as you call gpg --homedir because it will invoke gpg-agent with the correct --homedir flag.

So, all you need to do now is to rsync your gnupg dir on the SD card to some temp dir, e.g. /dev/shm/gnupg and use this dir as an argument to --homedir, and don't care about the agent at all.

codemac · 2014-11-26 06:08:01

Some background: traditionally gpg-agent is started by a DE (e.g. xfce4-session starts it). This is useful because gpg-agent also manages ssh keys. However, this is not required anymore because agents are started on-demand and multiple agents can run concurrently.

Agents cannot run concurrently, gpg-agent will terminate itself if someone else is using it's socket. Even with --no-use-standard-socket lock files were used to help prevent two gpg-agents with two different socket files in the same $GNUPGHOME

       --disable-check-own-socket
              gpg-agent  employs  a periodic self-test to detect a stolen socket.  This usually means a second instance
              of gpg-agent has taken over the socket and gpg-agent will then terminate itself.  This option may be used
              to disable this self-test for debugging purposes.

And obviously, without --no-use-standard-socket, they'll all be using the same socket file per $GNUPGHOME (as gpg 2.1 enforces). Agents on different GNUPGHOME's could always run concurrently, but implies other obscene security risks. This is how the gpg development tests are run

So while your comments are welcome, they are largely incorrect.

The rsync idea is interesting, but does mean I need my own systemd unit to run the rsync on mount or something, when I'd rather just put the socket file somewhere else.

gpg 2.1 at a minimum broke nfs, cifs, vfat, and other filesystems with this update, and I don't consider that regression trivial. I've hacked up both a libassuan patch given the git commit suggestion, but it's incredibly ugly. A gpg patch that adds a gpg.conf setting for socketfile location also works locally and makes way more sense. Will post when I've figured out how to use gpg's development tests so I can prove to myself they are working.

codemac · 2014-12-02 18:40:55

Been running with my patch locally for a bit, but this has been solved upstream (in probably the weirdest, user unfriendly way possible, but it's not like I'm paying for gpg..)

https://bugs.g10code.com/gnupg/issue1752

FIRST UPGRADE TO GPG IN GIT

Create a file in your $GNUPGHOME with where you'd like the socket file to be:

%Assuan%
socket=/run/user/1000/gnupg/S.gpg-agent

Note that this can parse some variables, but not $USERID afaik.

Then set this as your user's systemd unit file:

[Unit]
Description=GnuPG private key agent
IgnoreOnIsolate=true

[Service]
Type=forking
# let gpg fail if the directory can't be made. Most likely this is
# because the directory already exists. Not a big deal.
ExecStartPre=/bin/sh -c "/usr/bin/mkdir -p /run/user/1000/gnupg || exit 0"
ExecStart=/usr/bin/gpg-agent --daemon --homedir=<wherevere your $GNUPGHOME is>
ExecStop=/usr/bin/pkill gpg-agent
Restart=on-abort

[Install]
WantedBy=default.target

And then:

systemctl start gpg-agent.service

and you're off

Last edited by codemac (2014-12-02 18:42:52)

codemac · 2015-01-01 23:25:37

Let it be known - 2.1.1 has been released in the Arch repos has been released as of 2014-12-16.

Arch Linux

#1 2014-11-25 20:37:08

[SOLVED]GPG no longer supports --no-use-standard-socket?

#2 2014-11-25 20:46:01

Re: [SOLVED]GPG no longer supports --no-use-standard-socket?

#3 2014-11-25 20:53:48

Re: [SOLVED]GPG no longer supports --no-use-standard-socket?

#4 2014-11-25 21:03:08

Re: [SOLVED]GPG no longer supports --no-use-standard-socket?

#5 2014-11-25 21:22:49

Re: [SOLVED]GPG no longer supports --no-use-standard-socket?

#6 2014-11-26 06:08:01

Re: [SOLVED]GPG no longer supports --no-use-standard-socket?

#7 2014-12-02 18:40:55

Re: [SOLVED]GPG no longer supports --no-use-standard-socket?

#8 2015-01-01 23:25:37

Re: [SOLVED]GPG no longer supports --no-use-standard-socket?

Board footer