Kevin J. McCarthy wrote: > [Apologies if this is a dup. It appears the mailing list ate my > previous patchbomb set.] > > This patch series fixes Ticket #3564. Currently a key whose primary uid > has an empty User-ID can not be used for encryption in mutt. > > The first patch changes parse_pub_line() to allow an empty User-ID field > for a pub record type. This will allow the key to have an address > record generated, although it will have a null addr field. The key > searching and key selection menus both iterate over address records, so > without at least one, the user is unable to search for or select such > a key. > > The second patch wraps usages of addr in NONULL() where needed. Most > of the mutt routines already have null checks in them. A few debug > messages and a couple places in the pgp_select_key menu needed to be > wrapped for safety. (They did not actually generate a segfault for me, but > better to be safe across platforms). > > As a side note, in pgp_getkeybystr, the comparison: > if (!*p || mutt_strcasecmp (p, pgp_keyid (k)) == 0 || > (!mutt_strncasecmp (p, "0x", 2) && !mutt_strcasecmp (p + 2, pgp_keyid > (k))) || > (option (OPTPGPLONGIDS) && !mutt_strncasecmp (p, "0x", 2) && > !mutt_strcasecmp (p + 2, k->keyid + 8)) || > mutt_stristr (a->addr, p)) > takes place inside the address matching loop. Only the last one is > actually matching against the address. The others could be pulled in > front of the loop. I was tempted, but decided to be conservative with > my changes for now :-). > > Gpgme does not seem to be affected by this bug.
Pushed.
signature.asc
Description: PGP signature
