Fix gpg issue with importing public key

[sssoleileraaa]

Fixes #251

[sssoleileraaa]

When you run the client in the development environment, it either starts a new gpg-agent process or uses one that is already running and connected to the same home-dir. If you delete the home-dir while the gpg-agent is still running then next time you try to start the client, you'll run into #251 because the agent won't be able to find private-keys-v1.d.

Either a developer needs to know that they should kill the gpg-agent after they delete the agent's home-dir (which will be located here: <sdc-home>/gpg) or we would have to somehow detect that the running agent's home-dir no longer exists and either kill it or point it to a new home-dir for new key creation.

The confusing thing about this whole issue is that <sdc-home>/gpg is recreated when the client starts, and the gpg-agent tries to generate a new key pair but says it can't import the private key. You would think we would be able to tell the gpg-agent, hey look it's your home-dir again, regenerate a new key-pair.

@redshiftzero - what do you think is reasonable to do in this case?

[redshiftzero]

update: the underlying issue appears to only be happening on debian (see details in #251). we chatted about this PR and decided that just killing the gpg-agent process for the sdc-home directory after we close the client (only in the dev env, i.e. in run.sh) is the best path forward (bonus: this will also close #215)

[sssoleileraaa]

@redshiftzero so the code is ready for final review. it now:

• fixes gpg: error building skey array: No such file or directory #251
• prevents an explosion of run.sh-generated gpg-agent daemons by no longer using mktemp
• ensures we run a new gpg-agent per dev client run

TODO: Create a separate issue for killing the gpg-agent that is run from the client code since that will most likely also be used in production

[redshiftzero]

nice! couple minor suggestions inline

[redshiftzero]

note this is not platform independent (mac doesn't use /tmp for tempdirs), so I think we want to keep the mktemp -d logic

[redshiftzero]

nit: ew -> new

[redshiftzero]

nice! 😎

what about using this in a bash trap (so that we can use mktemp above), i.e. here's a diff doing that based on your commit here:

diff --git a/run.sh b/run.sh
index 28fc9e3..e72b344 100755
--- a/run.sh
+++ b/run.sh
@@ -15,28 +15,25 @@ while [ -n "$1" ]; do
   shift
 done

-if [ -d "$SDC_HOME" ]; then
-  SDC_HOME=${SDC_HOME}
-else
-  SDC_HOME="/tmp/sdc-home"
-  mkdir -p "SDC_HOME"
-  chmod 0700 "$SDC_HOME"
-fi
+SDC_HOME=${SDC_HOME:-$(mktemp -d)}
 export SDC_HOME

 GPG_HOME="$SDC_HOME/gpg"
-mkdir -p "$GPG_HOME"
+mkdir -p "$SDC_HOME" "$GPG_HOME"
 chmod 0700 "$GPG_HOME"

+function cleanup {
+  # make sure a new gpg-agent is used for each run
+  PID=$(ps -ef | grep gpg-agent | grep "$GPG_HOME" | grep -v grep | awk '{print $2}')
+  if [ "$PID" ]; then
+    kill $PID
+  fi
+}
+trap cleanup EXIT
+
 echo "Running app with home directory: $SDC_HOME"
 echo ""

-# make sure a ew gpg-agent is used for each run
-PID=$(ps -ef | grep gpg-agent | grep "$GPG_HOME" | grep -v grep | awk '{print $2}')
-if [ "$PID" ]; then
-  kill "$PID"
-fi
-
 gpg --homedir "$GPG_HOME" --allow-secret-key-import --import tests/files/securedrop.gpg.asc &

 # create the database and config for local testing
@@ -44,4 +41,6 @@ gpg --homedir "$GPG_HOME" --allow-secret-key-import --import tests/files/secured

 wait

-exec python -m securedrop_client --sdc-home "$SDC_HOME" --no-proxy $@
+exec python -m securedrop_client --sdc-home "$SDC_HOME" --no-proxy $@ &
+
+wait

[sssoleileraaa]

making the client a bg process and waiting at the end did the trick! 💯

[redshiftzero]

beautiful! works as advertised, thanks @creviera