Messages get stuck in skeleton mode when sdc-home is ~/.securedrop_client

[sssoleileraaa]

Description

If you run the client for the first time when you specify sdc-home as ~/.securedrop_client the secret test key fails to get imported with run output:

gpg: key CC40EF1228271441/CC40EF1228271441: error sending to agent: No such file or directory
gpg: error building skey array: No such file or directory

STR

1. NUM_SOURCES=10 make dev
2. ./run.sh --sdc-home ~/.securedrop_client
3. Login

Expected

To see messages change from skeletons to decrypted messages

Actual

Messages do not decrypt and are stuck as skeletons

[ntoll]

@creviera this is totally weird. I've been looking at this for a while and here's what happens:

1. When I start the client with LOGLEVEL=debug ./run.sh --sdc-home ~/.securedrop_client then I see the behaviour you report no matter if I click a source or not. (I always make sure the ~/.securedrop_client directory doesn't exist.)
2. When I start the client with LOGLEVEL=debug ./run.sh --sdc-home ~/.foobarbaz (i.e. some other non-existent sdc-home setting) then the app works as expected and the sources update away from skeleton mode.
3. If I just start the client via run.sh (with a temporary sdc-home dir) it all works fine too.

Not sure what's going on, but documenting progress.

Investigating further... 🪲 👣 🔍 ❓ 😕

[ntoll]

Obligatory screenie... ;-)

[ntoll]

Interesting... from the logs.

gpg: decryption failed: No secret key

[ntoll]

Aha... found the problem.

TL;DR: When the home directory is ~/.securedrop_client and run for the first time, then the secret keys are not copied over to the right place for some (likely GPG-related) reason.

For instance, given the ~/.securedrop_client/gpg and ~/.blahblah/gpg directories which have acted as arguments for the --sdc-home flag, I see the following:

ntoll@heraclitus:~/.securedrop_client/gpg$ ls
pubring.kbx  pubring.kbx~  trustdb.gpg
ntoll@heraclitus:~/.blahblah/gpg$ cd ~/.blahblah/gpg
ntoll@heraclitus:~/.blahblah/gpg$ ls
private-keys-v1.d  pubring.kbx  pubring.kbx~  trustdb.gpg

Furthermore, on client start I see:

$ LOGLEVEL=debug ./run.sh --sdc-home ~/.securedrop_client
Running app with home directory: /home/ntoll/.securedrop_client

Current OS is *not* Qubes, disabling DispVM support...
gpg: keybox '/home/ntoll/.securedrop_client/gpg/pubring.kbx' created
gpg: /home/ntoll/.securedrop_client/gpg/trustdb.gpg: trustdb created
gpg: key CC40EF1228271441: public key "SecureDrop Test/Development (DO NOT USE IN PRODUCTION)" imported
gpg: key CC40EF1228271441/CC40EF1228271441: error sending to agent: No such file or directory
gpg: error building skey array: No such file or directory
gpg: Total number processed: 1
gpg:               imported: 1
gpg:       secret keys read: 1

Note the messages: error sending to agent: No such file or directory and error building skey array: No such file or directory.

Interestingly, if I delete any pre-existing --sdc-home locations and try to run again to recreate that location I see exactly the same error.

My feeling is this is to do with GPG and the previously deleted directory being in some sort of a cache somewhere (so perhaps it's expecting a state that no longer exists on the filesystem). I don't know since I'm not a GPG expert in any sense of the word.

Next step is to hit Google with those error messages. ;-)

[ntoll]

OK... I can confirm that the fix is to restart GPG in some form or other -- in my case, none of the suggested commands appeared to work for me, so I rebooted my machine. 😱

I suggest this is more a configuration issue than a problem with the client..? I believe it can be closed. @creviera @eloquence @redshiftzero ???

[sssoleileraaa]

Thanks for the helpful notes during your investigation @ntoll! I think you came up with a better STR (start the client with home dir specified as ~/.securedrop_client and run for the first time) - instead of closing this issue, we should just update the steps to repro in the issue description (I'll do it since you're done for the day).

Running through this again, I also see that we get an error when trying to import the secret test key.

./run.sh --sdc-home ~/.securedrop_client
Running app with home directory: /home/creviera/.securedrop_client

Current OS is *not* Qubes, disabling DispVM support...
gpg: keybox '/home/creviera/.securedrop_client/gpg/pubring.kbx' created
gpg: /home/creviera/.securedrop_client/gpg/trustdb.gpg: trustdb created
gpg: key CC40EF1228271441: public key "SecureDrop Test/Development (DO NOT USE IN PRODUCTION)" imported
gpg: key CC40EF1228271441/CC40EF1228271441: error sending to agent: No such file or directory
gpg: error building skey array: No such file or directory
gpg: Total number processed: 1
gpg:               imported: 1
gpg:       secret keys read: 1

Versus:

./run.sh                                
Running app with home directory: /tmp/tmp.m00FQvBP5E

gpg: keybox '/tmp/tmp.m00FQvBP5E/gpg/pubring.kbx' created
Current OS is *not* Qubes, disabling DispVM support...
gpg: /tmp/tmp.m00FQvBP5E/gpg/trustdb.gpg: trustdb created
gpg: key CC40EF1228271441: public key "SecureDrop Test/Development (DO NOT USE IN PRODUCTION)" imported
gpg: key CC40EF1228271441: secret key imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg:       secret keys read: 1
gpg:   secret keys imported: 1

[rmol]

I'm having trouble reproducing this now, but some reading suggests that that gpg-agent might be getting confused if $GNUPGHOME is getting deleted and recreated.

If either of you is able to repro this now, could you try adding a line invoking the cleanup function at line 37 of run.sh and see if that fixes it?

[rmol]

@ntoll @creviera You could instead try #949; it's the more complete fix.