Ultimate ownertrust does not (always) imply ultimate validity in default trust model
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	infinity0
	Dec 23 2014, 4:09 AM

Description

$ gpg2 --version
gpg (GnuPG) 2.1.1
libgcrypt 1.6.2
[..]

make a clean homedir to test with

$ mkdir gpg && chmod 700 gpg

import my own key

$ gpg2 --homedir gpg --keyserver pool.sks-keyservers.net --recv-keys
0x1318efac5fbbdbce
gpg: keybox 'gpg/pubring.kbx' created
gpg: gpg/trustdb.gpg: trustdb created
gpg: key 5FBBDBCE: public key "Ximin Luo <infinity0@pwned.gg>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1

on first import, key has unknown validity

$ gpg2 --homedir gpg -k 0x1318efac5fbbdbce
pub rsa4096/5FBBDBCE 2010-08-03 [expires: 2016-01-01]
uid [ unknown] Ximin Luo <infinity0@pwned.gg>
uid [ unknown] Ximin Luo <infinity0@gmx.com>
uid [ unknown] Ximin Luo <infinity0@torproject.org>
uid [ unknown] Ximin Luo <infinity0@freenetproject.org>
sub rsa4096/91B24B90 2012-09-22 [expires: 2016-01-01]
sub rsa4096/8F650B79 2013-06-14 [expires: 2016-01-01]
sub elg4096/F77B29F4 2014-08-01 [expires: 2015-02-27]

set ultimate ownertrust

$ gpg2 --homedir gpg --edit-key 0x1318efac5fbbdbce
gpg (GnuPG) 2.1.1; Copyright (C) 2014 Free Software Foundation, Inc.
[..]
gpg> trust
[..]
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? 5
Do you really want to set this key to ultimate trust? (y/N) y
[..]
Please note that the shown key validity is not necessarily correct
unless you restart the program.

gpg> save
Key not changed so no update needed.

now key also has ultimate validity

$ gpg2 --homedir gpg -k 0x1318efac5fbbdbce
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2016-01-01
pub rsa4096/5FBBDBCE 2010-08-03 [expires: 2016-01-01]
uid [ultimate] Ximin Luo <infinity0@pwned.gg>
uid [ultimate] Ximin Luo <infinity0@gmx.com>
uid [ultimate] Ximin Luo <infinity0@torproject.org>
uid [ultimate] Ximin Luo <infinity0@freenetproject.org>
sub rsa4096/91B24B90 2012-09-22 [expires: 2016-01-01]
sub rsa4096/8F650B79 2013-06-14 [expires: 2016-01-01]
sub elg4096/F77B29F4 2014-08-01 [expires: 2015-02-27]

import another key, signed by my key

$ gpg2 --homedir gpg --keyserver pool.sks-keyservers.net --recv-keys
0xCCD2ED94D21739E9
gpg: key D21739E9: public key "Daniel Kahn Gillmor <dkg@fifthhorseman.net>" imported
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 1 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1 valid: 1 signed: 1 trust: 1-, 0q, 0n, 0m, 0f, 0u
gpg: next trustdb check due at 2015-02-26
gpg: Total number processed: 1
gpg: imported: 1

why does importing another key make it have non-ultimate validity???

$ gpg2 --homedir gpg -k 0x1318efac5fbbdbce
pub rsa4096/5FBBDBCE 2010-08-03 [expires: 2016-01-01]
uid [ undef ] Ximin Luo <infinity0@pwned.gg>
uid [ undef ] Ximin Luo <infinity0@gmx.com>
uid [ undef ] Ximin Luo <infinity0@torproject.org>
uid [ undef ] Ximin Luo <infinity0@freenetproject.org>
sub rsa4096/91B24B90 2012-09-22 [expires: 2016-01-01]
sub rsa4096/8F650B79 2013-06-14 [expires: 2016-01-01]
sub elg4096/F77B29F4 2014-08-01 [expires: 2015-02-27]

yet the other key has full validity (because my key has signed it)???

$ gpg2 --homedir gpg -k 0xCCD2ED94D21739E9
pub rsa4096/D21739E9 2007-06-02 [expires: 2015-02-26]
uid [ full ] Daniel Kahn Gillmor <dkg@fifthhorseman.net>
uid [ unknown] Daniel Kahn Gillmor <dkg@aclu.org>
uid [ full ] Daniel Kahn Gillmor <dkg@debian.org>
uid [ full ] Daniel Kahn Gillmor <dkg@openflows.com>
uid [ unknown] [jpeg image of size 3515]
sub rsa2048/4BFA08E4 2008-06-19 [expires: 2015-02-26]
sub rsa4096/21484CFF 2007-06-02 [expires: 2015-02-26]
sub rsa4096/1BFDFA5C 2013-03-12 [expires: 2015-03-12]

direct trust model works fine...

$ gpg2 --homedir gpg --trust-model=direct -k 0x1318efac5fbbdbce
pub rsa4096/5FBBDBCE 2010-08-03 [expires: 2016-01-01]
uid [ultimate] Ximin Luo <infinity0@pwned.gg>
uid [ultimate] Ximin Luo <infinity0@gmx.com>
uid [ultimate] Ximin Luo <infinity0@torproject.org>
uid [ultimate] Ximin Luo <infinity0@freenetproject.org>
sub rsa4096/91B24B90 2012-09-22 [expires: 2016-01-01]
sub rsa4096/8F650B79 2013-06-14 [expires: 2016-01-01]
sub elg4096/F77B29F4 2014-08-01 [expires: 2015-02-27]

Details

Version: 2.1.1

Related Objects

Mentioned Here: rGc5956592c171: kbx: Call skipfnc callback to filter out keys

Event Timeline

infinity0 added projects: gnupg, Bug Report.Dec 23 2014, 4:09 AM

infinity0 set Version to 2.1.1.

infinity0 added a subscriber: infinity0.

For comparison, running the below commands using gpg 1.4.18, does *not* exhibit
the bug - after importing dkg's key, my own key's validity remains as "ultimate".

infinity0 reopened this task as Open.Dec 23 2014, 4:28 AM

I confirmed that --check-trustdb results broken trustdb.
We can check by --list-trustdb.

It should be something like:

rec 30, trust A405E58AB3725B396ED1B85C1318EFAC5FBBDBCE, ot=6, d=0, vl=34
rec 31, valid 10FBD3A5C90C815ECDE1D7F3B64A505EB55CC999, v=6, next=0
rec 32, valid 669CC039409AA2E143FDA46B0636052BB5875E07, v=6, next=31
rec 33, valid 8797B8E208A2F9947790975948D15DF75034A882, v=6, next=32
rec 34, valid 3B623D1260F1F12E06655DB6182516BB82E8F60F, v=6, next=33
rec 35, trust 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9, ot=0, d=0, vl=38
rec 36, valid F5118E19309A256D9C802AF3B8179AC5AA9D04E4, v=5, next=0
rec 37, valid 867625B137AE05F8579F82DC29B5EAF274386304, v=5, next=36
rec 38, valid 328A5C6C1B2F0891125ECBE4624276B5A2296478, v=5, next=37

But 2.1.1 updates like:

rec 30, trust A405E58AB3725B396ED1B85C1318EFAC5FBBDBCE, ot=6, d=1, vl=34
rec 31, valid 10FBD3A5C90C815ECDE1D7F3B64A505EB55CC999, v=2, next=0
rec 32, valid 669CC039409AA2E143FDA46B0636052BB5875E07, v=2, next=31
rec 33, valid 8797B8E208A2F9947790975948D15DF75034A882, v=2, next=32
rec 34, valid 3B623D1260F1F12E06655DB6182516BB82E8F60F, v=2, next=33
rec 35, trust 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9, ot=0, d=0, vl=38
rec 36, valid F5118E19309A256D9C802AF3B8179AC5AA9D04E4, v=5, next=0
rec 37, valid 867625B137AE05F8579F82DC29B5EAF274386304, v=5, next=36
rec 38, valid 328A5C6C1B2F0891125ECBE4624276B5A2296478, v=5, next=37

That is, DEPTH=1 and VALIDITY=2, which is wrong.

I investigated and realized that keybox_search function in kbx/keybox-search.c
is not yet mature. That is, it doesn't support skipfnc yet.

In this situation, something like following is needed:
diff --git a/g10/trustdb.c b/g10/trustdb.c
index 1bf664b..a946c29 100644

a/g10/trustdb.c

+++ b/g10/trustdb.c
@@ -1625,6 +1625,12 @@ validate_key_list (KEYDB_HANDLE hd, KeyHashTable full_trust,

merge_keys_and_selfsig (keyblock);
clear_kbnode_flags (keyblock);
pk = keyblock->pkt->pkt.public_key;

+ if (search_skipfnc (full_trust, pk->keyid, NULL))
+ {
+ release_kbnode(keyblock);
+ continue;
+ }
+

if (pk->has_expired || pk->flags.revoked)
  {
    /* it does not make sense to look further at those keys */

(removing the PPG-2 support wasn't the easy job expected)

gniibe: If you want to fix that, please assign the bug to you, otherwise I
assign it to me in a few days.

werner: Please go ahead.
I don't have enough knowledge about keybox implementation (and its plan).
My message is basically to share information, and my proposed change is not the
real fix, but something
pointing the (major) cause.

• werner claimed this task.Jan 5 2015, 6:04 PM

A patch has been submitted, which should fix the problem. commit c595659

Thanks, fixed in 2.1.2. (I had to run --edit-key and --check-trustdb first.)

Ultimate ownertrust does not (always) imply ultimate validity in default trust modelClosed, ResolvedPublicActions