The --list-keys should account for groups that are defined
Open, NormalPublic


If someone defines a group, it would be useful to be able to make queries on the group. E.g., consider this session:

$ gpg --list-keys 0x2A8E4C02
pub   rsa4096 2013-07-20 [SC]
uid           [ unknown] Richard Stallman <>
sub   rsa4096 2013-07-20 [E]

$ gpg --group freeswleaders=0x2A8E4C02 --list-keys freeswleaders
gpg: error reading key: No public key

IMO gpg should have included defined groups in the search for "freeswleaders". Rationale:

  • it's useful for a user to be able to verify that their group setting is in force
  • applications that call --list-keys with an argument to be able to present users with a shortlist showing relevant records. The shortlist should include all matches that will be found in other commands using the -r option.
  • if a user enters a string that matches both a pubkey AND a group, there is possibly a security risk that the --encrypt command that follows use of --list-keys selects a pubkey that the user didn't expect because it wasn't shown to the user.
  • there is a duplication of code functionality that could be considated. Note this mutt issue: Mutt has a "crypt-hook" feature to map addresses to pubkey IDs. The "group" feature serves the same purpose. But because --list-keys neglects groups, every app must implement this mapping.