Gpgtools MacGPG2 → 2.0.18

Comments and changes to this ticket

• You flagged this item as spam.
  

  pbro April 15th, 2011 @ 09:25 PM

  Comment: Perhaps related to #154 ? Main point in this ticket is the lack of password entry.

• You flagged this item as spam.
  

  pbro April 15th, 2011 @ 10:16 PM

  OK, I managed to fix it.

  The problem was that gpg-agent could not create the necessary socket in ~/.gnupg as this is on a NFS volume.

  So: Moved .gnupg to local HD, put a softlink in place. Now everything works as designed.

  However, the error messages did not help me in pinning down or solving that problem.

• You flagged this item as spam.
  

  Alex (via GPGTools) April 16th, 2011 @ 11:33 AM

  • Assigned user set to “Benjamin Donnachie”
  • State changed from “new” to “open”

  [bulk edit]

• You flagged this item as spam.
  

  Alex (via GPGTools) April 16th, 2011 @ 11:35 AM

  • Title changed from “No passphrase entry window” to “~/.gnupg on NFS volumes (was: "no passphrase entry window")”

• You flagged this item as spam.
  

  Benjamin Donnachie April 16th, 2011 @ 04:59 PM

  This is expected behaviour for non-local home directory.

  In this case, the option no-use-standard-socket (from memory, please
  check) should be added to ~/.gnupg/gpg-agent.conf to cause socket to
  be created under /tmp instead.

  Sent from my iPhone

• You flagged this item as spam.
  

  Alex (via GPGTools) April 16th, 2011 @ 05:04 PM

  Shouldn't this option be added to the config file automatically in case sockets can't be created?
  This could easily implemented in the installer - a better approach might be to have an automatic fallback.

  -- sent from my mobile phone,
  please excuse my brevity

• You flagged this item as spam.
  

  Benjamin Donnachie April 16th, 2011 @ 06:59 PM

  No - benefit for vast majority of users to use standard sockets - so
  much so that now adopted as default by upstream.

  Sent from my iPhone

• You flagged this item as spam.
  

  Alex (via GPGTools) April 16th, 2011 @ 08:01 PM

  When neither the installer should update the config file nor GnuPG will itself recognize this situation, then users, which uses an NFS home, can't use MacGPG2/GPGTools out-of-the-box. Sound not like an optimal solution.

• You flagged this item as spam.
  

  Benjamin Donnachie April 16th, 2011 @ 08:49 PM

  Breaking 99% of installs for rare use case even less ideal. Please
  submit patch for review.

  Sent from my iPhone

• You flagged this item as spam.
  

  Alex (via GPGTools) April 16th, 2011 @ 11:37 PM

  Maybe we're talking cross purposes. I'll make an example on how to implement this in the installer:

  ./testSockets.py $HOME/.gnupg/ || echo "no-use-standard-socket" >> $HOME/.gnupg/gpg.conf
  

  With testSockets.py:

  #!/usr/bin/python
  import sys, os
  from socket import *
  testfile = sys.argv[1] + "_tmp_"
  try:
      socket(AF_UNIX, SOCK_DGRAM).bind(testfile)
  except:
      sys.exit(1)
  finally:
      os.remove(testfile) if os.path.exists(testfile) else ''
  sys.exit(0)
  

• You flagged this item as spam.
  

  Alex (via GPGTools) October 18th, 2011 @ 09:45 AM

  • State changed from “open” to “fixed”
  • Milestone set to “2.0.18”
  • Importance changed from “Low” to “”

  Added this patch to the latest auto-fix installer. See https://github.com/GPGTools/GPGTools_Core/commit/85e67c18867b9237d5...

• 

  Support January 27th, 2012 @ 02:05 AM

  • State changed from “fixed” to “waiting”
  • Assigned user changed from “Benjamin Donnachie” to “Alex (via GPGTools)”

  @Alex: the patch is alright, but it has to go into gpg-agent.conf. Causes invalid option problem in gpg.conf.

• You flagged this item as spam.
  

  Alex (via GPGTools) January 27th, 2012 @ 07:49 AM

  • State changed from “waiting” to “released”

  Fixed on the 19th of December: https://github.com/GPGTools/GPGTools_Core/commit/63c5ce24699576c734... - maybe it's still part of on old installer?