Qubes Split-GPG does not encrypt to non-ultimately trusted gpg keys

[sjug]

Qubes OS version (e.g., R3.1):

3.2 RC 3

Affected TemplateVMs (e.g., fedora-23, if applicable):

fedora-23-minimal

---

Expected behavior:

Qubes split GPG can encrypt for a public key that has been imported into the key ring .

Actual behavior:

Qubes split GPG throws an error saying:
gpg: 0x0000000000000000: There is no assurance this key belongs to the named user
gpg: cannot open '/dev/tty': No such device or address

Steps to reproduce the behavior:

1. Import public key into Qubes split gpg: qubes-gpg-import-key or wrapper --import recipient.asc
2. Encrypt for the new recipient: qubes-gpg-client-wrapper --armor -o test.gpg --encrypt -r recipient@imported.com test
3. Error:
   gpg: 0x994078DC337BF570: There is no assurance this key belongs to the named user gpg: cannot open '/dev/tty': No such device or address

if we specify --no-tty we only get a different error, no function:
gpg: 0x994078DC337BF570: There is no assurance this key belongs to the named user gpg: Sorry, no terminal at all requested - can't get input

General notes:

If we set the key trust to ultimate (5) then split gpg will encrypt without error.
This cannot possibly be expected behaviour, how many keys are we marking as ultimately trusted?

---

Related issues:

[marmarek]

Apparently this is expected behavior of gpg2:

[user@testvm ~]$ gpg2 --armor -o test.gpg --encrypt -r 47D0468A52D052CA8A413EBEEA8B16AC7B26C712 test
gpg: 81CCD52C04B5B51C: There is no assurance this key belongs to the named user
sub  rsa2048/81CCD52C04B5B51C 2015-04-17 Test test2
 Primary key fingerprint: 47D0 468A 52D0 52CA 8A41  3EBE EA8B 16AC 7B26 C712
      Subkey fingerprint: CEAD F2F1 5191 07A3 796B  D924 81CC D52C 04B5 B51C

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) 
gpg: test: encryption failed: Unusable public key
[user@testvm ~]$ gpg2 --armor -o test.gpg --encrypt --batch -r 47D0468A52D052CA8A413EBEEA8B16AC7B26C712 test
gpg: 81CCD52C04B5B51C: There is no assurance this key belongs to the named user
gpg: test: encryption failed: Unusable public key

If you want to override this, add --alwayt-trust option:

[user@testvm ~]$ gpg2 --armor -o test.gpg --encrypt --always-trust -r 47D0468A52D052CA8A413EBEEA8B16AC7B26C712 test

[marmarek]

Apparently this is expected behavior of gpg2:

[user@testvm ~]$ gpg2 --armor -o test.gpg --encrypt -r 47D0468A52D052CA8A413EBEEA8B16AC7B26C712 test
gpg: 81CCD52C04B5B51C: There is no assurance this key belongs to the named user
sub  rsa2048/81CCD52C04B5B51C 2015-04-17 Test test2
 Primary key fingerprint: 47D0 468A 52D0 52CA 8A41  3EBE EA8B 16AC 7B26 C712
      Subkey fingerprint: CEAD F2F1 5191 07A3 796B  D924 81CC D52C 04B5 B51C

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) 
gpg: test: encryption failed: Unusable public key
[user@testvm ~]$ gpg2 --armor -o test.gpg --encrypt --batch -r 47D0468A52D052CA8A413EBEEA8B16AC7B26C712 test
gpg: 81CCD52C04B5B51C: There is no assurance this key belongs to the named user
gpg: test: encryption failed: Unusable public key

If you want to override this, add --alwayt-trust option:

[user@testvm ~]$ gpg2 --armor -o test.gpg --encrypt --always-trust -r 47D0468A52D052CA8A413EBEEA8B16AC7B26C712 test