Home → Stable →

gpg2 doesn't start agent properly if using --homedir.

• Edit

dunlapg

17 Nov, 2014 09:36 PM

gpg2 command-line

$ gpg2 --version gpg (GnuPG/MacGPG2) 2.0.22
libgcrypt 1.5.3

I've been trying to use tools like caff, and setups like having the master keys on a separate USB stick (normally offline) for a few days now, and often have run into problems.

After a lot of playing around with thing, I think I've narrowed down the problem:

• If you specify an alternate gpg home via the GNUPGHOME environment variable, and a gpg-agent has not been started for that home directory, it will start a new agent correctly for that homedir.

• If, after starting an agent with that alternate homedir, you subsequently run "gpg2 --homedir=$DIR", then gpg2 will correctly use the alternate agent and everything will work.

• However, if you haven't yet started an agent with that home directory, gpg-agent will not be started correctly; and any operation that requires your secret key will error out with this: gpg: can't connect to the agent: IPC connect call failed
  gpg: problem with the agent: No agent running
  gpg: no default secret key: Operation cancelled

Other observations:
* You can manually start gpg-agent with the --homedir=$DIR option, and everything will work. * If you run gpg2 with GNUPGHOME set, and then do "ps ax | grep gpg-agent", you'll see two agents running; but neither agent will have "--homedir" in the command-line.

Please describe what you did expect instead

gpg2 --homedir=[alternate-directory]

just works without having to manually create a gpg-agent or set GNUPGHOME.

If you remember, please describe the steps leading up to the problem.

Setup:
gpg2 --export-secret-keys > /tmp/secret-keys.gpg
gpg2 --homedir=/tmp/gnupg-testing
gpg2 --homedir=/tmp/gnupg-testing /tmp/secret-keys.gpg

Test 1:
gpg2 --homedir=/tmp/gnupg-testing --clearsign
[fails}

gpg-agent --homedir=/tmp/gnupg-testing --daemon

Test 2:
gpg2 --homedir=/tmp/gnupg-testing --clearsign
[succeeds]

(Don't forget to rm your secret keys again!)

1. Support Staff 1 Posted by Luke Le on 09 Jan, 2015 01:25 PM

   

   You might try to set the homedir option in gpg-agent.conf.
   This way, any gpg-agent should be started with the alternative homedir.
   Haven't tried this so can't say for sure.

   As an additional note, gpg-agent is started by gnupg2 by demand, so it's hard to determine when it will be started.

   • Edit

2. 2 Posted by dunlapg on 09 Jan, 2015 01:42 PM

   

   Thanks for your response! But it seems like you've missed a couple of things.

   My normal homedir works fine; but doesn't have my master private key. My master private key is on a USB stick that I keep in a safe place in my home. I want to use "--homedir=/Volume/SecretKeyUSB" when I'm using the master private key, but for normal signing / decryption I just want to use the normal homedir.

   To use your work-around for this I'd have to:
   * Edit gnu-agent.conf to point to /Volume/[blah] * Run gpg2 with --homedir=/Volume/[blah] * Edit gnu-agent.conf again to point to the normal directory.

   I already have a simpler functional work-around, which is to set GNUPGHOME. I reported this so that a proper fix could be made to the --homedir option (which is clearly just broken).

   Thanks again,
   -George

   • Edit

3. Support Staff 3 Posted by Luke Le on 09 Jan, 2015 01:43 PM

   

   Hmm... wouldn't this require to have two gpg-agents independently running? One that uses .gnupg as your homedir and one that uses your USB stick as the homedir?

   • Edit

4. 4 Posted by dunlapg on 09 Jan, 2015 01:49 PM

   

   Yes -- and if you see from my description above:

   "If you run gpg2 with GNUPGHOME set, and then do "ps ax | grep gpg-agent", you'll see two agents running."

   So it seems that the ability to have two gpg-agents running, each with different homedirs, is already well supported.

   So what works:

   • gpg2 --homedir=$alt when the alternate agent is running

   • gpg2 with GNUPGHOME=$alt set to the alternate homedir if the alternate agent is not running

   • gpg2 with GNUPGHOME=$alt set to the alternate homedir if the alternate agent is running

   What doesn't work:

   • gpg2 --homedir=$alt when the alternate agent is not running

   Just try it yourself; I've left pretty detailed instructions on how to reproduce this.

   • Edit

5. Support Staff 5 Posted by Luke Le on 09 Jan, 2015 01:59 PM

   

   It's very interesting to hear that two gpg-agent don't interfere with each other.
   I think this issue is best brought up on the gnupg-dev mailing list at gnupg.org
   It sounds like that when calling "gpg2 --homedir=$alt", gnupg checks if an agent is running and finds the normal (not alternate agent) and is happy. Instead it should check for an agent, which is connected to the socket at $alt/.S.gpg-agent and if it doesn't find one, start a new one with --homedir=$alt

   What you might try is to add the no-use-standard-socket option in gpg.agent conf (located in your gnupg home dir on your usb stick)

   • Edit

6. 6 Posted by dunlapg on 09 Jan, 2015 02:08 PM

   

   When you report a bug upstream, you should normally have built from the upstream sources rather than a repackaged version. This is because:

   • The packagers may have added some patches which caused the bug in the first place; it's annoying for the upstreams to spend time debugging a problem only to find out it wasn't their bug in the first place

   • You should be able to re-compile and test any proposed fixes to make sure it actually fixes your original problem.

   I work as an open-source developer, and in our project we normally recommend that people using packaged versions of our software report bugs to the packagers first. Which is why, since I'm using your package, I reported the bug to you. :-)

   • Edit

7. Support Staff 7 Posted by Luke Le on 09 Jan, 2015 02:10 PM

   

   While I agree with you in general, in this case it's first to be determined I think, if the behavior you're expecting is supposed to work in the way you're expecting it.
   And that answer is best found on the gnupg users or devel mailing list.

   • Edit

8. Steve closed this discussion on 04 Jun, 2015 04:27 PM.

9. Steve re-opened this discussion on 08 Nov, 2023 04:56 PM

10. Steve closed this discussion on 08 Nov, 2023 04:56 PM.