Repeatedly prompts for GPG passphrase

[jasonrudolph]

Description

Each time I commit, Atom prompts me to enter my GPG passphrase.

Steps to Reproduce

1. Stage some changes
2. Commit the changes and enter your GPG passphrase when prompted
3. Stage some more changes
4. Commit the changes and observe that you are once again prompted for your GPG passphrase

See demo gif below.

Expected behavior:

In step 4 above, I expected Atom to commit the changes without prompting me for my GPG passphrase (since I already provided the passphrase in Step 2).

Actual behavior:

Atom prompts for my GPG passphrase every time I commit.

Reproduces how often:

100%

Versions

macOS 10.12.6

$ atom --version
Atom    : 1.21.0-dev-44f3cf73e
Electron: 1.6.9
Chrome  : 56.0.2924.87
Node    : 7.4.0

$ apm --version
apm  1.18.5
npm  3.10.10
node 6.9.5 x64
python 2.7.10
git 2.14.1

$ apm show github
github
├── 0.5.0
├── https://github.com/atom/github
├── GitHub integration
├── 7295 downloads
└── 16 stars

Demo

---

If there's additional info I can provide to help debug this issue, please let me know. 🙇

[jasonrudolph]

If I downgrade from github@0.5.0 to github@0.4.0, it resolves this issue.

With github@0.5.0, each time I attempt to commit, I see the following errors in Console.app:

error	10:59:41.845759 -0400	kernel	loginwindow is not entitled
error	10:59:41.845819 -0400	kernel	loginwindow is not entitled
error	10:59:41.845830 -0400	kernel	rcd is not entitled
error	10:59:41.845864 -0400	kernel	loginwindow is not entitled
error	10:59:41.845878 -0400	kernel	rcd is not entitled
error	10:59:41.845912 -0400	kernel	rcd is not entitled

[jasonrudolph]

@smashwilson: I think this issue was introduced in #1110. Does that sound feasible based on the info below?

---

I've done the following locally:

$ git checkout atom/github

$ git show | head -n1
993ee65e Merge pull request #1043 from Xapphire13/commitButton (Michelle Tilley, 5 days ago)

$ apm install

$ apm link

At this point, I observed the bug described in the issue body. Then, I reverted the changes from #1110:

$ git revert -m1 7835bc46d9f8dec07b6072293b788866db191bff
error: could not revert 7835bc46... Merge pull request #1110 from atom/aw-asarify-gpg
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

$ git diff package.json
diff --cc package.json
index 12000f02,20fa59a3..00000000
--- a/package.json
+++ b/package.json
@@@ -1,7 -1,7 +1,11 @@@
  {
    "name": "github",
    "main": "./lib/index",
++<<<<<<< HEAD
 +  "version": "0.5.0",
++=======
+   "version": "0.5.0-0",
++>>>>>>> parent of 7835bc46... Merge pull request #1110 from atom/aw-asarify-gpg
    "description": "GitHub integration",
    "repository": "https://github.com/atom/github",
    "license": "MIT",

$ # resolve conflict in editor

$ grep '"version"' package.json
  "version": "0.5.0-0",

$ apm install

At this point, when I reload Atom, I no longer observe the issue.

[smashwilson]

@jasonrudolph sorry for taking so long to get to this 😅

First of all: which version of gpg are you using to sign your commits? You can verify this by running:

$(git config gpg.program || echo 'gpg') --version

Do you have a gpg-agent running, and if so, what version is it?

gpg-agent --version
ps -ef | grep gpg-agent

@smashwilson: I think this issue was introduced in #1110. Does that sound feasible based on the info below?

Looking over that PR, it's entirely possible that this was introduced by the changes to gpgExec(), although I don't see how right now.

Can you enable git diagnostics if they aren't already:

# Run in your devtools
atom.config.set('github.gitDiagnostics', true)

Then try a commit, expand the git:git commit -m... line(s)?

For the first commit, you should see two commit commands like this:

And this is what I see for subsequent commits:

You'll likely see another "failure to commit" message on the second commit... if so, apply this patch to get more information about the gpg exec that's failing:

diff --git a/bin/gpg-wrapper.sh b/bin/gpg-wrapper.sh
index baee34d8..c67e2e73 100755
--- a/bin/gpg-wrapper.sh
+++ b/bin/gpg-wrapper.sh
@@ -1,5 +1,7 @@
 #!/bin/sh
 set -e
+set -x
+exec 2>/tmp/gpg.log 1>&2
 
 # Read the "real" GPG program from the git repository configuration, defaulting to a PATH search for "gpg" just
 # as git itself does.

Commits will fail with that patch, but you'll have a logfile in /tmp/gpg.log that will show the actual error you're getting from the underlying gpg process.

[jasonrudolph]

@smashwilson: Nice work on the instructions for gathering forensics. ⚡

which version of gpg are you using to sign your commits?

Bash complains about the command you mentioned, but I think this will give you the info you're looking for. 🤞

$ (git config gpg.program || echo 'gpg') --version
-bash: syntax error near unexpected token `--version'

$ gpg --version
gpg (GnuPG/MacGPG2) 2.0.30
libgcrypt 1.6.6

Do you have a gpg-agent running, and if so, what version is it?

$ gpg-agent --version
gpg-agent (GnuPG/MacGPG2) 2.0.30
libgcrypt 1.6.6
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ ps -ef | grep gpg-agent
  501  1586     1   0  6:37PM ??         0:00.01 /bin/bash /usr/local/MacGPG2/libexec/shutdown-gpg-agent
  501  1695     1   0  6:37PM ??         0:00.83 /usr/local/MacGPG2/bin/gpg-agent --daemon
  501 21318   482   0 10:09AM ttys002    0:00.00 grep gpg-agent

Can you enable git diagnostics if they aren't already:
Then try a commit, expand the git:git commit -m... line(s)?
For the first commit, you should see two commit commands like this:

Here's what I see for the first commit:

And this is what I see for subsequent commits:

And here's what I see for the next commit:

You'll likely see another "failure to commit" message on the second commit... if so, apply this patch to get more information about the gpg exec that's failing:

Done. See below. 😄

Commits will fail with that patch, but you'll have a logfile in ``/tmp/gpg.log` that will show the actual error you're getting from the underlying gpg process.

$ cat /tmp/gpg.log
+ unset GIT_CONFIG_PARAMETERS
++ git config gpg.program
10:21:18.897522 git.c:328               trace: built-in: git 'config' 'gpg.program'
++ echo gpg
+ GPG_PROGRAM=gpg
+ PASSPHRASE_ARG=
+ '[' -n /tmp/github-11786-22703-1x4ugsh.3h4wijm7vi/git-askpass-atom.js ']'
+ '[' -n /tmp/github-11786-22703-1x4ugsh.3h4wijm7vi/git-askpass-atom.sh ']'
++ git config user.signingkey
10:21:18.904513 git.c:328               trace: built-in: git 'config' 'user.signingkey'
+ SIGNING_KEY=B760F197E561DF15
+ '[' -n B760F197E561DF15 ']'
+ PROMPT='Please enter the passphrase for the GPG key '\''B760F197E561DF15'\''.'
++ /tmp/github-11786-22703-1x4ugsh.3h4wijm7vi/git-askpass-atom.sh 'Please enter the passphrase for the GPG key '\''B760F197E561DF15'\''.'
git-askpass-atom: no user askpass specified
git-askpass-atom: requesting dialog through Atom socket
git-askpass-atom: prompt = "Please enter the passphrase for the GPG key 'B760F197E561DF15'."
git-askpass-atom: connection established
git-askpass-atom: writing payload
git-askpass-atom: payload written
git-askpass-atom: Atom socket stream terminated
git-askpass-atom: Atom reply parsed
git-askpass-atom: success
+ PASSPHRASE='🙅‍ REDACTED 🙅‍'
+ PASSPHRASE_ARG='--passphrase-fd 3'
+ exec gpg --batch --no-tty --yes --passphrase-fd 3 --status-fd=2 -bsau B760F197E561DF15
[GNUPG:] USERID_HINT B760F197E561DF15 Jason Rudolph <jason@jasonrudolph.com>
[GNUPG:] NEED_PASSPHRASE B760F197E561DF15 B760F197E561DF15 1 0
[GNUPG:] GOOD_PASSPHRASE
[GNUPG:] BEGIN_SIGNING H8
[GNUPG:] SIG_CREATED D 1 8 00 1504707685 651EF90D325E1378FB803F1BB760F197E561DF15
-----BEGIN PGP SIGNATURE-----
🙅‍ REDACTED 🙅‍
-----END PGP SIGNATURE-----

[smashwilson]

I've figured out what's going on and I've started to put together a fix. I didn't get quite far enough to push a branch up but hopefully I'll have a PR together shortly. Essentially, the first trial call of a GPG-using command is missing the --batch --no-tty arguments, so it's still trying to interact with the non-existent tty before it checks your agent.

I do need to shuffle some code around first to get access to our outside-of-the-.asar /tmp directory and helper scripts even when we're running commands that aren't expected to talk back to Atom to trigger the credential dialog. There's also one odd case that I'm still thinking of the best fix for: if you run a git pull that requires a login, and your login succeeds, but the GPG signing of the merge commit it creates fails, I'd like to avoid re-prompting for the login credentials, too.

/cc @iolsen