If none of the uids are primary (because none are valid) then pick the
first to be primary (but still invalid). This is for cosmetics in case
some display needs to print a user ID from a non-selfsigned key. Also use
--allow-non-selfsigned-uid to make such a key valid and not
--always-trust. The key is *not* automatically trusted via
--allow-non-selfsigned-uid.
Make sure non-selfsigned uids print [uncertain] on verification even
though one is primary now.
If the main key is not valid, then neither are the subkeys.
Allow --allow-non-selfsigned-uid to work on completely unsigned keys.
Print the uids in UTF8. Remove mark_non_selfsigned_uids_valid()
Show revocation key as UTF8.
Allow --not-dash-escaped to work with v3 keys.
that has been revoked by designated revoker, but the designated revoker is
not present to verify the revocation (whew!). This applies to all ways to
get a key into the system: --import --recv-keys, and --search-keys. If
auto-key-retrieve is set, try and retrieve the revocation key.
Also, auto-key-retrieve is now a keyserver-option.
support. That is, it handles all the data to mark a key as revoked if it
has been revoked by a designated revoker. The second half (coming
later) will contain the code to make someones key your designated revoker
and to issue revocations for someone else.
Note that this is written so that a revoked revoker can still issue
revocations: i.e. If A revokes B, but A is revoked, B is still revoked.
I'm not completely convinced this is the proper behavior, but it matches
how PGP does it. It does at least have the advantage of much simpler code
- my first version of this had lots of loop maintaining code so you could
chain revokers many levels deep and if D was revoked, C was not, which
meant that B was, and so on. It was sort of scary, actually.
This also changes importing to allow bringing in more revocation keys, and
exporting to not export revocation keys marked "sensitive".
The --edit menu information will show if a revocation key is present.
