split-gpg2 client exits non-zero when importing public keys

[ben-grande]

Qubes OS release

R4.2

Brief summary

When import a public key for the first time to a split-gpg2 client, it has a delay as the agent doesn't respond, imports the key but exits non zero. What I am currently doing to overcome the error exit code:

• Checking if the regex ^\[GNUPG:\] IMPORT_OK appears in stderr
• Overriding agent with --agent-program="$(gpgconf --list-components | awk -F: '/^gpg-agent:/{print $3}')"

Steps to reproduce

Add a new public key (not previously imported) to the client keyring.

Expected behavior

Import happens successfully and exits with code zero. The /usr/share/split-gpg2/gpg-agent-placeholder should reply with something useful when importing a key, not only exit zero.

Actual behavior

Import happens successfully, but it has a delay and exits with code non-zero.

gpg --status-fd=2 --homedir=/tmp/tmp.mWSPrpSXoW --import salt/qubes-builder/files/client/qusal/keys/DF3834875B65758713D92E91A475969DE4E371E3.asc

[GNUPG:] KEY_CONSIDERED DF3834875B65758713D92E91A475969DE4E371E3 0
gpg: key A475969DE4E371E3: public key "Ben Grande (Code signing key) <[email protected]>" imported
[GNUPG:] IMPORTED A475969DE4E371E3 Ben Grande (Code signing key) <[email protected]>
[GNUPG:] IMPORT_OK 1 DF3834875B65758713D92E91A475969DE4E371E3
gpg: can't connect to the agent: IPC connect call failed
gpg: Total number processed: 1
gpg:               imported: 1
[GNUPG:] IMPORT_RES 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0
[GNUPG:] KEY_CONSIDERED DF3834875B65758713D92E91A475969DE4E371E3 0
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
zsh: exit 2     gpg --homedir=/tmp/tmp.kre9T3wViO --import

[marmarek]

What does it do with the agent? Agent is responsible for handling only secret keys... Maybe it tries to check if it has secret part for this key? Can you enabled debugging in the split-gpg2 and see what it tries to do? See debug_log option in the config: https://github.com/QubesOS/qubes-app-linux-split-gpg2/blob/main/qubes-split-gpg2.conf.example

[marmarek]

Or maybe just journalctl/.xsession-errors in the backend will have that info already?

[ben-grande]

What does it do with the agent? Agent is responsible for handling only secret keys... Maybe it tries to check if it has secret part for this key?

Possibly tries to check if there is a secret part.

Can you enabled debugging in the split-gpg2 and see what it tries to do?

Checked the dom0 logs now and it never calls the split-gpg2 backend, nothing logged to the journal of qubes-qrexec-policy-daemon.

[marmarek]

hmm, does it mean split-gpg2 isn't working for you there at all? maybe the client part fails to start or such?

[ben-grande]

split-gpg2 works fine, I can list secret keys only available in the backend.