Sorry, Werner, but I have to disagree on this. Specifying them by fingerprint only works if you have a specific field for the key (including the case where you are just it on the config file).

The case were we stumbled upon it was in the context of Request Tracker, which uses gpg as backend, and calls it with --default-key and the email address associated to the current queue. [1] Thus, there's no fingerprint to specify separately, it's just the email you are signing with.

After your message I have been pondering about alternate ways of solving it, but there doesn't seem to be good options.

Manually mapping the email into the fingerprint of the latest key by using group withing gpg.conf doesn't work, since --default-key and --local-user don't expand groups.

Ensuring that the last key is the first one found would be perfect, but storing the newest key appear first seems brittle for a classic keyring, and I don't even know how to reorder them with a keybox keyring.

Replacing --default-key with --local-user might be an option (plus changing the library they use to support that [2]). I have digged a little on the code history, but I don't know why they went with --default-key, if they are equivalent for what they use it for or not.

The problem seems to lie on gpg, with --default-key behaving unlike other options.

I would be ok with a new parameter that controlled the behavior of --default-key (old/new way) if backwards compatibility is so important, but I don't really find compelling that the user expectation was really to have a matching yet invalid key (expired or revoked, I guess?) and also having on their keyring a non-expired or non-revoked one and not wanting to use those instead but a completely different default key, so as to need such switch.

1- https://github.com/bestpractical/rt/blob/stable/lib/RT/Crypt/GnuPG.pm
2- https://metacpan.org/pod/GnuPG::Interface has default_key[3] but I see no local_user
3- https://metacpan.org/pod/GnuPG::Options#default_key