Page MenuHome GnuPG

gpg: decryption failed: No secret key <= after debian upgrade from Jessie to Stretch
Open, NormalPublic


Upgrading from Jessie to Stretch seems to have crossed this line where gpg 2.1.18 is now in action. So when "gpg -d" is executed on a past e-mail, the output is "gpg: decryption failed: No secret key". This file exists:


The man page says that's an old file, and mentions this file:


File indicating that a migration to GnuPG 2.1 has been done.

That file also exists and is zero in size. Yet I still cannot decrypt my email. The FaQ says:

"To ease the migration to the no-secring method, gpg detects the presence of a secring.gpg and converts the keys on-the-fly to the the key store of gpg-agent (this is the private-keys-v1.d directory below the GnuPG home directory (~/.gnupg)). This is done only once and an existing secring.gpg is then not anymore touched by gpg."

That apparently did not happen correctly. The directory ~/.gnupg/private-keys-v1.d exists but it is empty.

Note that I did not use debian's "dist-upgrade" tool. Instead I installed Debian Stretch from scratch, and copied my $HOME contents.



Event Timeline

I got it working.. turns out I had to force a migration by doing an rm ~/.gnupg/.gpg-v21-migrated.

I think it's still a bug though, because the file ~/.gnupg/.gpg-v21-migrated should not have been created in the absence of the secring.gpg file. Anyone who copies the $HOME data after installation will get burnt as I did.

Did you run gpg before your copying $HOME data and after your installation of Stretch?
That gpg invocation create the file ~/.gnupg/.gpg-v21-migrated, which marks "the migration finished".


I don't recall, but I suppose I did. It may not have been a manual invocation, but possibly a batch job from mutt or something.

werner triaged this task as Normal priority.Apr 17 2018, 8:08 PM