Decryption fails with "No secret key"

[Gabriele Pohl]

Hi Ingo,

On Sun, 05 Jan 2020 16:17:04 +0100
Ingo Klöcker wrote:

with your recipe 

> all you have to do is to remove the file ~/.gnupg/.gpg-v21-migrated

the missing secret key was migrated again
and decryption is possible now :-)

The key listing now shows:

----------- snip -----------

Secret key is available.

sec  rsa2048/9C7646202CE0CBB2
     created: 2012-09-05  expires: 2020-03-16  usage: SC  
     trust: ultimate      validity: ultimate
ssb  rsa2048/51E12CABCB4F0264
     created: 2012-09-05  expired: 2016-09-04  usage: E   
ssb  rsa4096/4BB3049F19616A80
     created: 2016-09-05  expires: 2020-03-16  usage: E   
ssb  rsa4096/534EADA0332CFAAF
     created: 2016-09-09  expired: 2018-09-09  usage: S   
[ultimate] (1). Gabriele Pohl <contact at dipohl.de>

----------- snip -----------


> The secret key of subkey 4BB3049F19616A80 is not available (it's listed as 
> "sub", but not as "ssb"). Only the secret keys of the main key and the expired 
> subkey are available.
> 
> I suspect a gpg1 vs. gpg2 problem, i.e. the secret key of subkey 
> 4BB3049F19616A80 is only available to gpg1 or gpg2, but not to both (they use 
> different key storages). Fedora 30 probably used gpg2 when you run 'gpg' while 
> the previous version used gpg1.

hmmm, I searched for fedora bug reports (before I wrote
to this mailing list) but didn't find my issue there.

I reckon there are not many users who add encryption keys
to an existent key and this special case may be the 
reason for the problem arising in my case.
I think it is too late to file a bug report now
as the move from Fedora 29 to 30 is no longer relevant.

And by searching the internet this thread may arise 
in the future for lucky finders ;-)


Thank you very much for your help and kind regards,

Gabriele