Page MenuHome GnuPG

gpg: New key has unknown trust after generation
Closed, ResolvedPublic

Description

I have just generated a new (cert-only) OpenPGP key and was surprised that it was not ultimately trusted after the generation. I used Kleopatra master with gpg master, but gpg-agent was most likely from 2.3.7. It also happens with gpg (and gpg-agent) 2.3.7 (openSUSE Tumbleweed) and with gpg + gpg-agent master.

$ grep trust [...]/gpg.conf
no-auto-check-trustdb

$ gpg --full-generate-key --expert
gpg (GnuPG) 2.3.8-beta28; Copyright (C) 2021 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
Please select what kind of key you want:
   (1) RSA and RSA
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
   (9) ECC (sign and encrypt) *default*
  (10) ECC (sign only)
  (11) ECC (set your own capabilities)
  (13) Existing key
  (14) Existing key from card
Your selection? 11

Possible actions for this ECC key: Sign Certify Authenticate 
Current allowed actions: Sign Certify 

   (S) Toggle the sign capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? s

Possible actions for this ECC key: Sign Certify Authenticate 
Current allowed actions: Certify 

   (S) Toggle the sign capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? 
Please select which elliptic curve you want:
   (1) Curve 25519 *default*
   (2) Curve 448
   (3) NIST P-256
   (4) NIST P-384
   (5) NIST P-521
   (6) Brainpool P-256
   (7) Brainpool P-384
   (8) Brainpool P-512
   (9) secp256k1
Your selection? 
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 
Key does not expire at all
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: Cert-only Test Key
Email address: 
Comment: 
You selected this USER-ID:
    "Cert-only Test Key"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: revocation certificate stored as '[...]/openpgp-revocs.d/784F113E37857546A7CD489983DEB53A659B9FB4.rev'
public and secret key created and signed.

pub   ed25519 2022-09-08 [C]
      784F113E37857546A7CD489983DEB53A659B9FB4
uid                      Cert-only Test Key

$ gpg -K 784F113E37857546A7CD489983DEB53A659B9FB4
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: please do a --check-trustdb
sec   ed25519 2022-09-08 [C]
      784F113E37857546A7CD489983DEB53A659B9FB4
uid           [ unknown] Cert-only Test Key

Details

Version
2.3.7

Event Timeline

werner edited projects, added Not A Bug; removed Bug Report.
werner added a subscriber: werner.

If you run gpg --export-ownertrust you will notice that the trust has been set to ultimate (value is 6). However, due to the no-auto-check-trustdb in your gpg.conf that will valeu will only be shown after running gpg --check-trustdb. The value shown in the key listing is the computed value and the computation is done by --check-trustdb. I don't see a bug here.

aheinecke claimed this task.
aheinecke added a subscriber: aheinecke.

I agree. We have to get rid of auto check trustdb and such stuff. I always found that impossible to program around because it either takes a long time (check-trustdb) or it might return invalid results (no check).
The solution for this is keyboxd.

keyboxd has nothing to do with this, it merely makes the lookup of keys a bit faster. The computation of the WoT itself takes long and there is no shortcut for it. Fortunately most users don't have a deeply meshed WoT with dedicated revokers etc., thus for them things are fast in the standard configuration.

keyboxd has nothing to do with this, it merely makes the lookup of keys a bit faster. The computation of the WoT itself takes long and there is no shortcut for it. Fortunately most users don't have a deeply meshed WoT with dedicated revokers etc., thus for them things are fast in the standard configuration.

What I meant by "We have to get rid of auto check trustdb and such stuff" is that users (me included!) want to solve the problem that keylistings can take ages and use the current options available to improve that speed. Keyboxd will help because users will not search our manuals for key listing speed improvements anymore when keyboxd does its job.

To clarify that I meant that the underlying problem is our current keylisting speed in Kleopatra I have opened T6206.