4

I was running Evolution on Debian buster (testing) amd64 with GnuPG to encrypt mails. I have my GPG private key on a YubiKey actings as GPG smartcard. As Evolution somehow failed to load my calendars using CalDAV, I resetted Evolution. CalDAV is working fine now.

But after the reset another issue appeared: GPG encrypting/signing isn't working anymore. Mails are decrypted without problems.

Furthermore, I can not choose my own GPG key in the account's settings, even if it is imported properly and gets listed in gpg -K:

enter image description here

I'm now able to choose my key.

When I try to send an encryoted mail this fails with Evolution showing the following error:

Could not create message. You may need to select different mail options. Detailed error: Failed to encrypt: Invalid recipient <[email protected]> specified. A common issue is that the gpg2 doesn’t have imported public key for this recipient. 

But my public key is imported. The same thing happens when I disable the option Always encrypt to myself when sending encrypted messages with this account. The error then is:

Detailed error: Failed to encrypt: Invalid recipient <[email protected]> specified. A common issue is that the gpg2 doesn’t have imported public key for this recipient. 

Encrypting/signing from command line with the gpg command works fine. Using a private key which is not on a smartcard also did not work. Resetting both GPG and Evolution did not work.

I don't have any idea now what I should do now. Thank you all in advance :)

EDIT: output of strace -p $(pidof evolution) -f -e trace=execve when decrypting (works fine):

[pid 4613] execve("/usr/local/bin/gpg2", ["gpg2", "--verbose", "--no-secmem-warning", "--no-greeting", "--no-tty", "--status-fd=66", "--command-fd=67", "--verify-options", "show-photos", "--photo-viewer", "/usr/lib/evolution/camel-gpg-pho"..., "--decrypt", "--output", "-"], [/* 34 vars */]) = -1 ENOENT (No such file or directory) [pid 4613] execve("/usr/bin/gpg2", ["gpg2", "--verbose", "--no-secmem-warning", "--no-greeting", "--no-tty", "--status-fd=66", "--command-fd=67", "--verify-options", "show-photos", "--photo-viewer", "/usr/lib/evolution/camel-gpg-pho"..., "--decrypt", "--output", "-"], [/* 34 vars */]) = 0 

When encrypting (which fails):

[pid 4537] execve("/usr/local/bin/gpg2", ["gpg2", "--verbose", "--no-secmem-warning", "--no-greeting", "--no-tty", "--batch", "--yes", "--status-fd=67", "--encrypt", "--armor", "-u", "[email protected]", "-r", "<[email protected]>", "--output", "-"], [/* 34 vars */]) = -1 ENOENT (No such file or directory) [pid 4537] execve("/usr/bin/gpg2", ["gpg2", "--verbose", "--no-secmem-warning", "--no-greeting", "--no-tty", "--batch", "--yes", "--status-fd=67", "--encrypt", "--armor", "-u", "[email protected]", "-r", "<[email protected]>", "--output", "-"], [/* 34 vars */]) = 0 

The file /usr/local/bin/gpg2 doesn't exist and seems not to be part of any Debian package.

EDIT2: The command @Hauke Laging posted in the comments works, but I interactively needed to confirm to execute the action (as it also was when I manually encrypted using the command line):

echo foo | /usr/bin/gpg2 --status-fd=1 --encrypt --armor -u [email protected] -r [email protected] --output - 

While the command which Evolution wants to execute fails (I removed the <> as that causes issues with zsh):

➜ ~ gpg2 --verbose --no-secmem-warning --no-greeting --no-tty --batch --yes --status-fd=67 --encrypt --armor -u [email protected] -r [email protected] --output gpg: Fatal: status-fd is invalid: Bad file descriptor 

Setting --status-fd=1 still fails, but with different errors:

➜ ~ echo "foo" | gpg2 --verbose --no-secmem-warning --no-greeting --no-tty --batch --yes --status-fd=1 --encrypt --armor -u [email protected] -r [email protected] --output - [GNUPG:] KEY_CONSIDERED <recipient's key fingerprint> 0 gpg: using pgp trust model gpg: using subkey <recipient's encryption subkey id> instead of primary key <recipient's primary key id> [GNUPG:] KEY_CONSIDERED <recipient's key fingerprint> 0 gpg: automatically retrieved '[email protected]' via Local gpg: <recipient's encryption subkey id>: There is no assurance this key belongs to the named user [GNUPG:] INV_RECP 10 [email protected] [GNUPG:] FAILURE encrypt 53 gpg: [stdin]: encryption failed: Unusable public key 

EDIT3: Just tested: signing messages from Evolution works as well as decrypting.

When I manually encrypt a message using the command line, I get the following message which I think causes this issue:

➜ ~ echo "foo" | gpg --encrypt -r [email protected] --armor gpg: automatically retrieved '[email protected]' via Local gpg: <recipient's encryption subkey id>: There is no assurance this key belongs to the named user sub rsa4096/<recipient's encryption subkey id> 2015-10-14 Recipient's Name <[email protected]> Primary key fingerprint: <recipient's key fingerprint> Subkey fingerprint: <recipient's encryption subkey fingerprint> It is NOT certain that the key belongs to the person named in the user ID. If you *really* know what you are doing, you may answer the next question with yes. Use this key anyway? (y/N) y -----BEGIN PGP MESSAGE----- [...] -----END PGP MESSAGE----- 

EDIT4: As the message above is caused by missing ownertrust (at least I think so), I'd like to set the recipient's ownertrust using gpg --edit-key (which was not set before):

gpg> trust pub rsa4096/<some key id> created: <some date in the past> expires: <some date in the future> usage: SCA trust: unknown validity: unknown sub rsa4096/<some other key id> created: <some date in the past> expires: <some date in the future> usage: E [ unknown] (1). Pecipient's Name <[email protected]> Please decide how far you trust this user to correctly verify other users' keys (by looking at passports, checking fingerprints from different sources, etc.) 1 = I don't know or won't say 2 = I do NOT trust 3 = I trust marginally 4 = I trust fully 5 = I trust ultimately m = back to the main menu Your decision? 3 pub rsa4096/<some key id> created: <some date in the past> expires: <some date in the future> usage: SCA trust: marginal validity: unknown sub rsa4096/<some other key id> created: <some date in the past> expires: <some date in the future> usage: E [ unknown] (1). Pecipient's Name <[email protected]> 

So I set the recipient's ownertrust, but why is there still this [ unknown] at the end?

7
  • Do you have several versions of GnuPG installed (maybe without being aware)? Commented Nov 2, 2017 at 22:15
  • I'm not sure be it seems like I have only gpg2 installed: gist.github.com/anonymous/278ca7838d4cb05f43f0bb111df11d2e I don't think that the old gpg1 is still available on debian buster. /usr/bin/gpg2 is also a symlink to gpg, so I dont think that I have several gpg versions. Commented Nov 3, 2017 at 11:10
  • Can you attach strace -p $PID -f -e trace=execve to Evolution? What is the exact gpg call? Commented Nov 3, 2017 at 12:11
  • See my edit above :) Commented Nov 3, 2017 at 18:44
  • echo foo | /usr/bin/gpg2 --status-fd=1 --encrypt --armor -u [email protected] -r [email protected] --output - works? Commented Nov 3, 2017 at 19:02

2 Answers 2

3

You haven't understood how the OpenPGP validity scheme works. But independent of that: Applications should not have a problem using non-valid keys (so you might complain towards the Evolution developers).

There are two ways (with GnuPG in standard mode) how a certificate can become valid:

  1. Its ownertrust is set to ultimate.
  2. It has a (valid, i.e. non-expired) signature from a valid (i.e. non-expired) signature from a key with ultimate ownertrust.

This means: If no certificate in your keyring has ultimate ownertrust then you have automatically lost.

Alternatively you can change the trust model with

--trust-model direct 

Then you can set the validity directly as you tried. But in any case the certificate must be "completely valid". Marginal validity is not enough.

I have explained that in detail on my web site:

http://www.hauke-laging.de/sicherheit/openpgp.html#wot

The text is German but there are some images in that block which might be helpful for understanding.

3

Enabling Always trust keys in my keyring for encrypting solved the problem for me.

1
  • 1
    Either that, or sign the public key of the recipient in your gpg keybox Commented Nov 26, 2021 at 13:19

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.