Question

18

Why is gpg getting upset and how do I stop it?

rated 0 times [ 18] [ 0] / answers: 1 / hits: 25617 / 1 Year ago, wed, april 26, 2023, 11:37:18

I recently migrated from one installation of Ubuntu to another, and in the process changed my username. I imported my public/private key pair into gpg, and while decryption (using my private key) works fine, whenever I attempt to encrypt something to myself with my public key I get the following warning message:

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.

After that it asks me whether I really want to use the key (I always answer "yes", because it is in fact the only key in my keyring and I know where it came from). I can decrypt stuff just fine, so why does gpg throw a hissy fit whenever I try to encrypt something? And how can I prevent this message from appearing again?

Answers

Only authorized users can answer the question. Please sign in first, or register a free account.

ciousuntru

Add To Favorites

Follow

Total Points: 352

Total Questions: 124

Total Answers: 95

Location: Grenada

Member since Tue, Oct 12, 2021

3 Years ago

answered 1 Year ago inglehare · Accepted Answer

I managed to reproduce the problem which you are experiencing. I did so doing the following:

$ gpg --no-default-keyring --keyring ./test-keyring  --secret-keyring ./test-secring --trustdb-name ./test-trustdb --no-random-seed-file --gen-key



<specified parameters and let it do its thing>



gpg: key 58018BFE marked as ultimately trusted

public and secret key created and signed.



<snip>



$

Notice that the process marked the key as "ultimately trusted".

Now I export the keys:

$gpg --no-default-keyring --keyring ./test-keyring  --secret-keyring ./test-secring --trustdb-name ./test-trustdb --no-random-seed-file --export-secret-keys -a >private.key



$gpg --no-default-keyring --keyring ./test-keyring  --secret-keyring ./test-secring --trustdb-name ./test-trustdb --no-random-seed-file --export -a > public.key

Now I import to a new gpg database:

$gpg --no-default-keyring --keyring ./test2-keyring  --secret-keyring ./test2-secring --trustdb-name ./test2-trustdb --no-random-seed-file --import public.key



$gpg --no-default-keyring --keyring ./test2-keyring  --secret-keyring ./test2-secring --trustdb-name ./test2-trustdb --no-random-seed-file --import private.key

Now if I attempt to encrypt using the new keyrings I get:

$ gpg --no-default-keyring --keyring ./test2-keyring  --secret-keyring ./test2-secring --trustdb-name ./test2-trustdb --no-random-seed-file -r Fake -e

gpg: AE3034E1: There is no assurance this key belongs to the named user



pub  1024R/AE3034E1 2013-06-13 Fake User <[email protected]>

 Primary key fingerprint: AD4D BAFB 3960 6F9D 47C1  23BE B2E1 67A6 5801 8BFE

      Subkey fingerprint: 58F2 3669 B8BD 1DFC 8B12  096F 5D19 AB91 AE30 34E1



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.

The reason for this is the "web of trust" model. By default, in order for a public key to be trusted, it requires either 1 "ultimate" trust certificate (typically where you personally have verified the identities of the people involved), or 3 "marginal" trust certificates (where somebody you know, who knows somebody you know ... has signed the certificate).

Because gpg is a security application, it warns you if you are attempting to encrypt to a key which is not listed as trusted. The reason your own key isn't trusted in this case is simple. It is because you did not export the trust relationships from the previous gpg instance. To do this, use the --export-ownertrust and --import-ownertrust commands.

As always, refer to the man page.