aheinecke wrote regarding not showing the group at all (https://dev.gnupg.org/T6401#175847):

I think from a users standpoint that is too intransparent. The user needs to see that there is a group there and that this group has a certificate in it that is problematic, only then they can start to somehow try to remedy that situation by asking for an updated key for that user for example. Just skipping the whole group is confusing in that case. And leads the user to think that there is a bug or problem with the software and not with the certificate group configuration.

With https://dev.gnupg.org/T6701 you can now even encrypt to an expired or even revoked S/MIME certificate if you chose to do so. I have to test if that is the case with --always-trust in OpenPGP, too. Then I could basically place the same error handling there. Another alternative would then be to not to encrypt to this specific key by chosing the option from the combobox, so all the people with "correct" keys in the group will get the mail but the one person who has for example the expired key will not be able to decrypt the mail. This moves the problem then from the senders side who can now still encrypt to most of the group, to the receivers side with the e.g. expired key to send / publish around an updated key to all the people they want to keep in touch with.

So I would prefer if groups that are not fully acceptable would also be expanded for OpenPGP too.

again aheinecke:

I think as long as we ensure that an expired key is never preferred in the sort order we should show it, at least to make the problem discoverable and then even allow to "Force" encryption even to that expired key, like we now have for S/MIME with T6559 although that works a bit differently, for S/MIME in GpgOL i first try to encrypt, and if that fails I bring up the error dialog and then ask the user "Do you want to try harder" ("WARNING: This is not VS-NfD compliant.") And I think if you really want to encrypt something it is better to send something to an expired key because you likely just have not received the update. As the alternative is usually to not encrypt at all because it is to difficult. So while I hate message boxes that users tend to ignore anyway, I think we should show expired / revoked keys before we don't show any keys at all.

TBH when I look at the code I think its an unintended side effect that expired keys are not shown.

I left this comment there:

/* Also list unusable keys to make it transparent why they are unusable */

And apparently this filters out expired / revoked keys:

> class OpenPGPFilter : public DefaultKeyFilter
> {
> public:
>     OpenPGPFilter()
>         : DefaultKeyFilter()
>     {
>         setIsOpenPGP(DefaultKeyFilter::Set);
>         setCanEncrypt(DefaultKeyFilter::Set);
>     }
> };

While this does not:

> class SMIMEFilter : public DefaultKeyFilter
> {
> public:
>     SMIMEFilter()
>         : DefaultKeyFilter()
>     {
>         setIsOpenPGP(DefaultKeyFilter::NotSet);
>         setCanEncrypt(DefaultKeyFilter::Set);
>     }
> };

See also https://dev.gnupg.org/T6401#176099 which explains why OpenPGP seems to behave differently than S/MIME.

We discussed and decided that "can encrypt" should determine if an encryption subkey exists for a key in the keyring associated with the given email address.

If that key is expired, it should be displayed appropriately marked and the encryption button greyed out.

In case of a key group this has the consequence that the keys in the group will be resolved and the user can decide if the message should be encrypted to the remaining, not expired keys only.

With the above changes a group with an expired key is now expanded. But, as in T6742, the key is shown with the blue info icon instead of with a red X icon and the OK button is enabled.