Home → Stable →

Agent not working when specifying a non-standard home directory

• Edit

Basic XP

01 Nov, 2013 02:40 PM

I am having a problem with the GPG Agent not working when specifying a non-standard directory for gpg on command line.
Configuration files were copied over from ~/.gnupg. The program works properly without specifying a home directory. I am using a non-standard path to store my master secret key separately from the keychain that's going to be used daily.

Steps to reproduce:

1. Run the following command:
   

   gpg --homedir="$(pwd)" --lock-never --no-permission-warning --expert --gen-key
   

2. Input all the required parameters
   
3. Attempt to generate a new key

Actual result:

An error occurs when the program tries to access the GPG Agent to securely request a password.

gpg: can't connect to the agent: IPC connect call failed
gpg: problem with the agent: No agent running

Expected result:

GPG Agent starts up, asks for a password, key generation completes successfully.

Attachments:

Снимок экрана 2013-11-01 в 18.19.48.png: error screenshot
gpg.conf: GnuPG configuration
gpg-agent.conf: GPG Agent configuration

Environment:

Mac OS X 10.9 build 13A603
GPG Tools: stable build from October, 22nd
GnuPG: 2.0.22
libgcrypt: 1.5.3

• Снимок_экрана_2013-11-01_в_18.19.48.png 144 KB
• gpg-agent.conf 130 Bytes
• gpg.conf 528 Bytes

1. 1 Posted by Basic XP on 02 Nov, 2013 11:00 AM

   

   This is what's output when GPG is run in verbose mode:
   

   gpg: no running gpg-agent - starting one
   gpg: waiting 5 seconds for the agent to come up
   gpg: can't connect to the agent: IPC connect call failed
   gpg: problem with the agent: No agent running
   gpg: no running gpg-agent - starting one
   gpg: waiting 5 seconds for the agent to come up
   gpg: can't connect to the agent: IPC connect call failed
   gpg: problem with the agent: No agent running
   gpg: Key generation canceled.
   

   Yet, if I run gpg-agent, it tells me that the agent is actually running:
   

   gpg-agent: gpg-agent running and available
   

   • Edit

2. 2 Posted by Basic XP on 03 Nov, 2013 08:24 AM

   

   Same problem has been reported by someone on the gnupg-users maillist, but, sadly, there was no solution.
   http://lists.gnupg.org/pipermail/gnupg-users/2012-April/044138.html

   • Edit

3. 3 Posted by Mento on 07 Nov, 2013 03:38 PM

   

   Try to start the gpg-agent using the following command:
   

   gpg-agent --homedir="$(pwd)" --daemon
   

   • Edit

4. 4 Posted by Basic XP on 07 Nov, 2013 06:05 PM

   

   I thought the agent should start up automatically. Anyway, this made the situation better, but did not completely solve it. The location of the external keychain is on an exFAT TrueCrypt volume. This lead to two problems, only one of which I was able to solve:

   1. It can't create a socket file on such a file system. Got over this by telling GnuPG to use the /tmp folder instead, saving environment info in a file and then sourcing it in a script. Here's the script I'm using (I know, it's terribly inefficient, just a temporary solution, a better option is always welcome :D ):
      

      #!/bin/bash
      PWD=$(pwd)
      GPGAGENT_CMDLINE="gpg-agent --homedir ${PWD}"
      GPGAGENT_CMDLINE_FULL="$GPGAGENT_CMDLINE --daemon --no-use-standard-socket --write-env-file ${PWD}/gpg-agent.env"
      function gpa_pid() {
      echo $(ps x | grep -m1 "$GPGAGENT_CMDLINE" | grep -v grep | awk '{ print $1 }')
      }
      GPGAGENT_PID=$(gpa_pid)
      [ "$GPGAGENT_PID" == "" ] && $($GPGAGENT_CMDLINE_FULL)
      GPGAGENT_PID=$(gpa_pid)
      source ${PWD}/gpg-agent.env
      LANG=en gpg --homedir="${PWD}" --lock-never --no-permission-warning --expert $*
      kill $GPGAGENT_PID
      rm gpg-agent.env
      

   2. Even though the folder is writable and GnuPG automatically creates the pubring.gpg, secring.gpg and others, it can't write the key after it has been generated:
      

      gpg: no writable public keyring found: Unknown system error
      Key generation failed: Unknown system error
      

      No idea why this is happening, verbose mode doesn't provide any further information.
   • Edit

5. Support Staff 5 Posted by Luke Le on 07 Nov, 2013 06:23 PM

   

   Hi Roman,

   ah, we've seen such a TrueCrypt setup before.
   With patched --no-use-standard-socket so it uses a socked in a fixed position in /tmp, so the whole --write-env thingy shouldn't be necessary.
   I think --lock-never should also not be necessary.
   Could you remove those options and re-try it without the wrapper script.

   Could you try creating a key and adding the option --status-fd 1
   This might reveal some more information on what's going wrong.

   • Edit

6. 6 Posted by Basic XP on 07 Nov, 2013 06:50 PM

   

   Okay, so this is what I got now (started from scratch, removed all *.gpg files):
   

   basicxp@me665 /Volumes/Security/PGP % gpg-agent --homedir /Volumes/Security/PGP --daemon --no-use-standard-socket
   GPG_AGENT_INFO=/tmp/gpg-agent/basicxp/S.gpg-agent:2866:1; export GPG_AGENT_INFO;
   basicxp@me665 /Volumes/Security/PGP % LANG=en gpg --homedir /Volumes/Security/PGP --status-fd 1 -v --no-permission-warning --expert --gen-key
   gpg (GnuPG/MacGPG2) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc.
   This is free software: you are free to change and redistribute it.
   There is NO WARRANTY, to the extent permitted by law.
   gpg: lock not made: link() failed: Operation not supported
   gpg: can't lock /Volumes/Security/PGP/secring.gpg'
   gpg: DBG: Oops,/Volumes/Security/PGP/secring.gpg.lock' is not locked
   gpg: keyblock resource /Volumes/Security/PGP/secring.gpg': General error
   gpg: lock not made: link() failed: Operation not supported
   gpg: can't lock/Volumes/Security/PGP/pubring.gpg'
   gpg: DBG: Oops, /Volumes/Security/PGP/pubring.gpg.lock' is not locked
   gpg: keyblock resource/Volumes/Security/PGP/pubring.gpg': General error
   Please select what kind of key you want:
   [--snip--]
   You need a Passphrase to protect your secret key.
   [GNUPG:] NEED_PASSPHRASE_SYM 9 3 10
   We need to generate a lot of random bytes. It is a good idea to perform
   some other action (type on the keyboard, move the mouse, utilize the
   disks) during the prime generation; this gives the random number
   generator a better chance to gain enough entropy.
   [GNUPG:] PROGRESS primegen . 0 0
   [GNUPG:] PROGRESS primegen . 0 0
   [GNUPG:] PROGRESS primegen . 0 0
   [GNUPG:] PROGRESS primegen + 0 0
   [GNUPG:] PROGRESS primegen + 0 0
   [GNUPG:] PROGRESS primegen + 0 0
   [GNUPG:] PROGRESS primegen + 0 0
   [GNUPG:] PROGRESS primegen + 0 0
   [GNUPG:] PROGRESS primegen X 100 100
   [GNUPG:] PROGRESS primegen . 0 0
   [GNUPG:] PROGRESS primegen + 0 0
   [GNUPG:] PROGRESS primegen + 0 0
   [GNUPG:] PROGRESS primegen + 0 0
   [GNUPG:] PROGRESS primegen + 0 0
   [GNUPG:] PROGRESS primegen + 0 0
   [GNUPG:] PROGRESS primegen X 100 100
   gpg: writing self signature
   [GNUPG:] GOOD_PASSPHRASE
   gpg: RSA/SHA1 signature from: "0x0928ED8D [?]"
   gpg: no writable public keyring found: Unknown system error
   Key generation failed: Unknown system error
   [GNUPG:] ERROR key_generate 65535
   [GNUPG:] KEY_NOT_CREATED
   

   Seems that --lock-never is optional, it still proceeds without it, I just get lots of warnings in the beginning.
   • Edit

7. Support Staff 7 Posted by Luke Le on 19 Nov, 2013 06:15 PM

   

   Hi Roman,

   the problem here is that the usb/external drive you're using is probably not HFS+ formatted. In that case the link command doesn't work, which is used by gpg when locking a file.

   Unfortunately there is little we can do about this at the time, but we'll look into it.
   I've created a ticket for this problem where you can track progress:
   http://gpgtools.lighthouseapp.com/projects/66001/tickets/126

   • Edit

8. 8 Posted by Basic XP on 20 Nov, 2013 04:55 PM

   

   It is, as I mentioned above, indeed not HFS+ formatted, it's exFAT. But why is it trying to lock the file even when I explicitly tell it not to?

   • Edit

9. Support Staff 9 Posted by Steve on 29 Dec, 2013 10:21 PM

   

   Roman, we'll look into this. Sorry we don't have any results yet.

   I'm closing this discussion. It will be re-opened as soon as anything related to the ticket Luke mentioned.

   steve

   • Edit

10. Steve closed this discussion on 29 Dec, 2013 10:21 PM.