Release: 1.2.2

Environment

SunOS 5.8, sparc,Sun-Blade-100

Description

Probably related to the bug that was the reason to release version 1.2.2:

After creating a new UserID NU (and making it primary) the new primary UserID NU gets all validity that the old primary UserID OU has, despite the fact that the new UserID NU does not have any signatures at all. Changing the primary UserID back to the old primary UserID OU gets OU back the validity it had before the whole new UserID creation began and leaves
the new UserID NU correctly with no validity since it has not collected any signatures.

How To Repeat

1. create DSA/ElGamal Keypair A (with one single UserID A)
2. set owner trust of key A to be the ultimatly trusted default key
3. create DSA/ElGamal Keypair B (with one single UserID B)
4. set the owner trust of key B to be not known/empty
5. Key A signs key B
6. Check for the validity of B. UserID B of key B is fully valid.
7. Now add UserID b to key B. This becomes automatically the primary UserID of key B and 'inherits' all validity that was previously assigned to UserID B. This is despite the fact that UserID b does not have any signatures.
8. Make UserID B the primary UserID of key B again. UserID b loses all validity, ok it does not have any signatures, correct. UserID B gets full validity, it as As signature.
9. If you make UserID b the primary UserID of key B again, this is starting all over and UserID b does get full validity, which is wrong since it has no signature from key A.

Fix

Define the above described behaviour to be the standard behaviour when switching primary UserIDs and document it.

:-)

Siriously: I am not sure if this is a bug or a feature of gpg.

From a usability perspective it does make sense to transfer
the validity of an old primary UserID to the new primary UserID. Otherwise a user can start collecting all his
signatures again when adding a _new_primary_ UserID.
If a user add a new UserID but does not make it primary
everything seems fine.

Take care

Reimer