Weird behaviours in GPG 2.1 with validity

[Damien Goutte-Gattat]

On 12/23/2014 04:14 AM, Ximin Luo wrote:
> I've managed to trim this down to a minimal test case:
>
> https://bugs.g10code.com/gnupg/issue1794
>
> Would be good if others could confirm and/or comment.

I have just observed the same problem when trying to convert my legacy 
pubring.gpg to the new keybox format.

If that can help, here is another test case (you can find the keys and 
the ownertrust file attached to this message):

   $ mkdir test && chmod 0700 test

   # Importing Alice and Bob keys (each key is signed by the other)
   $ gpg2 --homedir ./test --import alice.asc bob.asc
   gpg: keybox './test/pubring.kbx' created
   gpg: ./test/trustdb.gpg: trustdb created
   gpg: key 525487D8: public key "Alice <alice at example.net>" imported
   gpg: key 2748ECD9: public key "Robert <bob at example.com>" imported
   gpg: Total number processed: 2
   gpg:               imported: 2
   gpg: no ultimately trusted keys found

   # Restoring ownertrust
   #   Alice's key is "ultimately" trusted
   #   Bob's key is "marginally" trusted
   $ gpg2 --homedir ./test --import-ownertrust otrust.lst
   gpg: inserting ownertrust of 6
   gpg: inserting ownertrust of 4

   # Displaying calculated validity of both keys
   # Note that Alice's key is only marginally valid
   $ gpg2 --homedir ./test --list-options show-uid-validity --list-keys
   gpg: checking the trustdb
   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: 0-, 0q, 0n, 1m, 0f, 0u
   ./test/pubring.kbx
   ------------------
   pub   nistp256/525487D8 2014-12-26
   uid       [marginal] Alice <alice at example.net>
   sub   nistp256/529A1EF5 2014-12-26 nistp256

   pub   nistp256/2748ECD9 2014-12-26
   uid       [  full  ] Robert <bob at example.com>
   sub   nistp256/A5D8267D 2014-12-26 nistp256


The problem only occurs when using the new keybox format. If I do the 
same thing as above, but this time forcing gpg2 to use the legacy 
pubring format (by touch'ing an empty pubring.gpg prior to importing the 
keys), Alice's key remains ultimately valid.

The fix proposed in the BTS [1] works for me.


[1] https://bugs.g10code.com/gnupg/msg5688
-------------- next part --------------
# List of assigned trustvalues, created Fri 26 Dec 2014 04:57:19 AM CET
# (Use "gpg --import-ownertrust" to restore them)
CF1F914B89FDE5371C258CB4DF8FE60A525487D8:6:
B464CBBBBE41D6BA348CA849885CC1552748ECD9:4:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: alice.asc
Type: application/pgp-encrypted
Size: 800 bytes
Desc: not available
URL: </pipermail/attachments/20141226/48a5b4cb/attachment.pgp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bob.asc
Type: application/pgp-encrypted
Size: 796 bytes
Desc: not available
URL: </pipermail/attachments/20141226/48a5b4cb/attachment-0001.pgp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141226/48a5b4cb/attachment.sig>