To summarize the scope of this bug: Using a special manual procedure, typically performed using GnuPG, users create a special key file, which consists of a primary key and sub keys, which doesn't contain the secret key for the primary key, but which contains the secret keys for the subkeys.
When Thunderbird attempts to import a secret key file, RNP reports all keys as secret keys, including the primary key with the missing secret key. Thunderbird attempts to unlock it, but RNP reports a failure (because there is no secret key).
How can this be fixed?
With newer versions of RNP, a new function rnp_key_get_protection_type was added, which can allow an application to learn if there is really a secret key. We need to change Thunderbird to use that new function, and skip unlocking/using such unavailable secret keys.
I have an initial patch, I've tested with a key that has valid subkeys for encryption and signing, and it works.
Having this new kind of keys imported, we should improve the logic that decides whether imported secret key is suitable for being used as an email account's personal key. We should ensure that key material for at least one (valid) signing key is available, and for at least one (valid) encryption key.
While working on this code (checking if a code is valid for signing or encryption), I identified some unused scenarios that I didn't want to keep while modifying it - we don't use key flags for invalid or disabled keys.
Also, we should enable users to discover that an imported key lacks some secret (sub)keys. If we want to backport, we should a minimal flag somewhere. I've added a change in the structure tab of the key details dialog. If a key is of type key pair (with secret key), but the secret key material for a key is missing, we show (!) in front of the type of the subkey.