I do have two keys in my keychain that include the mail address for my main account. The account's GPG setting is "Select key by your email address". When enabling signing CM opens a dialog "Select Keys", listing the two keys matching the mail address. No matter which one I select I get this error message: Signature failed: Secret key specification is ambiguous Taking a look at the terminal output it looks like CM hands over the mail address to GPG (not the key ID), which is still ambiguous of course.
Hi, The "select key" dialog is for choosing recipient's keys for encryption, not secret key for signing. If you have two secret keys for signing, you will have to tell Claws (well, gpg) which one to use using the key ID.
So the dialog with my keys is opened because I have enabled "Encrypt messages with your own key in addition to recipient's"? Any reason not to use the dialog for choosing the signing key?
Or just the other way round... Why does CM ask for a key to encrypt to self when the account has configured fixed key?
I've been using a patch for a while that lets claws-mail automatically use the most recent encryption key in case of multiple matches. This is also useful when the recipient has multiple valid keys which otherwise results in having to choose a key manually for each mail which is somewhat annoying. In the patch this behavior is enabled by default, but can be "conveniently" disabled with gdb. Would the patch be acceptable if it was disabled by default and controlled with a (hidden) option? I agree that it would be nice if Claws-Mail would allow the user to specify a default encryption key independent of the gpg settings, but if I remember correctly this would require a lot more changes. It also wouldn't address the "multiple valid encryption keys for the recipient" scenario.
Created attachment 1181 [details] In case of multiple matching encryption keys, use the most recent one without bothering the user
Created attachment 1233 [details] In case of multiple matching encryption keys, use the most recent one without bothering the user The updated patch adds a NULL pointer check that was missing in the previous one.