On 2/23/21 2:56 PM, Carlos E.R. wrote:

On 23/02/2021 21.25, David C. Rankin wrote:

...

All,

This is a first for me. I was in tbird (68) and enigmail reported not being able to find the secret key to open my Drafts. Huh??

So I open konsole and did:

gpg --list-secret-keys --keyid-format LONG

And before rebooting it showed my 6 keys with "not found" shown after the key number. But after reboot, now

gpg --list-secret-keys --keyid-format LONG

shows NOTHING? Oh, this is bad. Using ls -al to look in

~/.gnupg/private-keys-v1.d/

There are 13 .key files there. There is also a ~/.gnupg/openpgp-revocs.d/ file -- ironically from 2/23/2017, but I don't see that being an issue.

There are ~/... backup? files in ~/.gnupg, e.g.

-rw------- 1 david david 3651976 Feb 22 17:56 pubring.gpg -rw------- 1 david david 3645612 Feb 22 17:56 pubring.gpg~ -rw-r--r-- 1 david david 66740 Feb 23 05:36 pubring.kbx -rw-r--r-- 1 david david 64241 Feb 23 05:06 pubring.kbx~

Where is ~/.gnupg/secring.gpg?

That is where the private keys are stored. Or were, I think it changed later to the directory .gnupg/private-keys-v1.d/

Where is ~/.gnupg/secring.gpg? That is where the private keys are stored. Or were, I think it changed later to the directory .gnupg/private-keys-v1.d/ =========== Sorry Had To Forward, Can't Reply, No Key ============== This is a Leap 15.0 install. Nothing has changed between working/non-working yesterday/today. (I know nothing changed in the last week, we had no power for 6 Days 6 Hours due to ice storm) The full listing of ~/.gnupg is: $ ~/.gnupg> l total 7476 drwx------ 5 david david 4096 Feb 23 14:40 . drwxr-xr-x 70 david david 4096 Feb 23 14:19 .. drwx------ 2 david david 4096 Apr 25 2016 crls.d drwx------ 2 david david 4096 Feb 23 2017 openpgp-revocs.d drwx------ 2 david david 4096 Nov 3 2019 private-keys-v1.d -rw-r--r-- 1 david david 0 Oct 28 2016 .gpg-v21-migrated -rw-r--r-- 1 david david 6963 Feb 19 2017 C0B2ADC8_ascii.txt -rw-r--r-- 1 david david 50 Mar 23 2016 agent.info -rw-r--r-- 1 david david 50 Nov 3 2019 agent.info-wizard:0 -rw------- 1 david david 42 Nov 4 2016 gpg-agent.conf -rw------- 1 david david 7677 Jan 16 2018 gpg.conf -rw-r--r-- 1 david david 6736 Oct 1 2015 public_rlf.asc -rw------- 1 david david 3651976 Feb 22 17:56 pubring.gpg -rw------- 1 david david 3645612 Feb 22 17:56 pubring.gpg~ -rw-r--r-- 1 david david 66740 Feb 23 05:36 pubring.kbx -rw-r--r-- 1 david david 64241 Feb 23 05:06 pubring.kbx~ -rw------- 1 david david 600 Feb 23 14:44 random_seed -rw------- 1 david david 28948 May 22 2017 secring.gpg -rw-r--r-- 1 david david 49152 Oct 13 07:05 tofu.db -rw------- 1 david david 5800 Feb 23 13:58 trustdb.gpg I don't want to try just re-importing all my keys until I understand what happened. This is just NUTS. gpg has lost its mind :) -- David C. Rankin, J.D.,P.E.

On 2/23/21 4:59 PM, Carlos E. R. wrote:

On 23/02/2021 23.10, David C. Rankin wrote:

...

On 2/23/21 2:56 PM, Carlos E.R. wrote:

...

On 23/02/2021 21.25, David C. Rankin wrote:

...

...

=========== Sorry Had To Forward, Can't Reply, No Key ==============

What do you mean, no key? Keyboard? GPG key? you do not need them if you do not sign or encrypt.

Forgot to delete that line, had to disable Enigmail in Tbird to be able to reply-to-list. Without disabling tbird wouldn't send due to no gpg key.

...

I don't want to try just re-importing all my keys until I understand what happened. This is just NUTS. gpg has lost its mind :)

You can create new user, copy the directory ~/.gnupg over, and chown it to the new user. Don't login graphically, use a terminal, do "su -" (don't forget the dash), and then use gnupg tools to verify things, not thunderbird.

You do not need to import anything this way.

Create new user, copied my ~/.gnupg to new user and chowed all to new user. Attempted to list private keys -- nothing. nothing listed at all. (I remembered the 'su -') I don't know the insides of gpg in detail. I can use it, create or import secret keys, etc., but I don't know how to verify or confirm what is currently wrong with what I currently have? It looks like it is all there to me. It just stopped working.... The same keyring on other boxes work just fine. What happened here? -- David C. Rankin, J.D.,P.E.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2021-02-23 at 19:16 -0600, David C. Rankin wrote:

On 2/23/21 6:55 PM, David C. Rankin wrote:

...

On 2/23/21 4:59 PM, Carlos E. R. wrote:

...

On 23/02/2021 23.10, David C. Rankin wrote:

...

...

...

I don't want to try just re-importing all my keys until I understand what happened. This is just NUTS. gpg has lost its mind :)

You can create new user, copy the directory ~/.gnupg over, and chown it to the new user. Don't login graphically, use a terminal, do "su -" (don't forget the dash), and then use gnupg tools to verify things, not thunderbird.

You do not need to import anything this way.

Create new user, copied my ~/.gnupg to new user and chowed all to new user. Attempted to list private keys -- nothing. nothing listed at all. (I remembered the 'su -')

I don't know the insides of gpg in detail. I can use it, create or import secret keys, etc., but I don't know how to verify or confirm what is currently wrong with what I currently have? It looks like it is all there to me. It just stopped working....

The same keyring on other boxes work just fine. What happened here?

Something just scrambled my gpg keys. I just pulled a working copy from an Arch box back to my laptop. Ran gpg and listed the secret keys fine. This means I have lost all 3M+ of all the public keys I had imported, and any changes to the private keys made of the past couple of years. Here are the "Working" and "Non-Working" private key listings:

The public keys are irrelevant, you can download them again as/when needed. The private keys... there can't be many changes. New keys, new identities, that's probably all.

Working

-rw------- 1 david david 1158 Jul 15 2018 049685C470C32CDB9CCECDB005B3088216E6D0E8.key -rw------- 1 david david 1158 Feb 23 2017 9465CEB4D9BC2DD20856045118D2CCEB9CD68D1D.key -rw-r----- 1 david david 1157 Oct 28 2016 4BCBB4EC81E9771758D140CCE69B7950BD9E5E44.key -rw------- 1 david david 1997 Oct 28 2016 66416C5701166D9EC8C8C011E6C016077C891500.key -rw------- 1 david david 1999 Oct 28 2016 66CB191C42978CC70B81BCC0648C75C5006148C0.key -rw------- 1 david david 1118 Oct 28 2016 78195CD4476C2C7D9EC7EB7C59206781459802DC.key -rw------- 1 david david 1174 Feb 29 2017 00D7206D0D7424C815465B2D62D0829C86052C77.key -rw------- 1 david david 1174 Jul 15 2018 C8BC2254BC819251C5259C708CC0540290969259.key -rw------- 1 david david 682 Nov 4 2016 D27002D1E0701B949B74E1B56B602CCD694E2C91.key -rw------- 1 david david 1921 Oct 28 2016 E51C9622787191B58861C0DDCDBC59119641B074.key -rw------- 1 david david 1116 Oct 28 2016 E60BCC95004E9049DB70E57D2B96CDB409D9D415.key -rw------- 1 david david 814 Oct 28 2016 E7191C4B0ED169E1C981196BC09907DB15DE1719.key -rw------- 1 david david 796 Dec 17 2016 E96DEB07C91B900175909DD665B8B819C49C189D.key

Non-working

-rw------- 1 david david 1158 Nov 9 2019 049685C470C92CDB9CCECDB005B9088216E6D0E8.key -rw------- 1 david david 1158 Feb 29 2017 9465CEB4D9BC2DD20856045118D2CCEB9CD68D1D.key -rw-r----- 1 david david 1157 Oct 28 2016 4BCBB4EC81E9771758D140CCE69B7950BD9E5E44.key -rw------- 1 david david 796 Oct 90 15:95 66416C5701166D9EC8C8C011E6C016077C891500.key

Oct 90? Really? Or is it year 90, not day 90?

-rw------- 1 david david 1999 Oct 28 2016 66CB191C42978CC70B81BCC0648C75C5006148C0.key -rw------- 1 david david 1118 Oct 28 2016 78195CD4476C2C7D9EC7EB7C59206781459802DC.key -rw------- 1 david david 1174 Feb 29 2017 00D7206D0D7424C815465B2D62D0829C86052C77.key -rw------- 1 david david 1174 Nov 9 2019 C8BC2254BC819251C5259C708CC0540290969259.key -rw------- 1 david david 682 Nov 4 2016 D27002D1E0701B949B74E1B56B602CCD694E2C91.key -rw------- 1 david david 1921 Oct 28 2016 E51C9622787191B58861C0DDCDBC59119641B074.key -rw------- 1 david david 1116 Oct 28 2016 E60BCC95004E9049DB70E57D2B96CDB409D9D415.key -rw------- 1 david david 814 Oct 28 2016 E7191C4B0ED169E1C981196BC09907DB15DE1719.key

(key ids have been changed to protect the innocent...)

Well, make a copy of the bad ones, move elsewhere, then replace with backup copy, or copy from another machine. Oh, you may do a byte by byte comparison of each, usin 'mc' for ease of use if you like.

The only event that I can even remotely think of that could have happened, is when I shutdown as the power went out, my office server had already shut down. So when I closed Tbird, shutting down Leap 15, it didn't really shut down and was forced-closed. I know that occurred, because when I logged in yesterday, Tbird launched automatically as I have "Restore previous session" selected in kcontrol Session Manager. So KDE didn't see Tbird as shut down when I shut down my laptop due to the power outage...

Now, I have NEVER, in 20+ years, heard of a shutdown like this causing any problems with gpg keys, so this is my best GUESS at what the possible cause is.

Only if some tool was working on the keys and had a copy in memory and wrote that.

I hope we have a gpg guru on the list that has thoughts at how to examine the state of the non-working ~/.gnupg files to try and identify what happened. (I have saved both an archive and the actual directory saved under a different name for that analysis)

... at least this is a new and different Linux issue to digest :)

I don't think the keys can be "analyzed". You can look at them with 'mc'. If gnupg doesn't recognize them, there is nothing you can do about that, but recover from backup. see "info gnupg". '--check-signatures' '--check-sigs' Same as '--list-keys', but the key signatures are verified and listed too. Note that for performance reasons the revocation status of a signing key is not shown. This command has the same effect as using '--list-keys' with '--with-sig-check'. The status of the verification is indicated by a flag directly following the "sig" tag (and thus before the flags described below. A "!" indicates that the signature has been successfully verified, a "-" denotes a bad signature and a "%" is used if an error occurred while checking the signature (e.g. a non supported algorithm). Signatures where the public key is not availabale are not listed; to see their keyids the command '--list-sigs' can be used. For each signature listed, there are several flags in between the signature status flag and keyid. These flags give additional information about each key signature. From left to right, they are the numbers 1-3 for certificate check level (see '--ask-cert-level'), "L" for a local or non-exportable signature (see '--lsign-key'), "R" for a nonRevocable signature (see the '--edit-key' command "nrsign"), "P" for a signature that contains a policy URL (see '--cert-policy-url'), "N" for a signature that contains a notation (see '--cert-notation'), "X" for an eXpired signature (see '--ask-cert-expire'), and the numbers 1-9 or "T" for 10 and above to indicate trust signature levels (see the '--edit-key' command "tsign"). '--locate-keys' Locate the keys given as arguments. This command basically uses the same algorithm as used when locating keys for encryption or signing and may thus be used to see what keys 'gpg2' might use. In particular external methods as defined by '--auto-key-locate' may be used to locate a key. Only public keys are listed. - -- Cheers, Carlos E. R. (from openSUSE 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYDXFwBwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVfg8An2NnMkeaCMpTsiQOb8h8 cglQSREBAKCAp7dc/UPDxVi1oL2xhQSZtyWEfw== =WFZb -----END PGP SIGNATURE-----

On 2/23/21 9:04 PM, Carlos E. R. wrote:

Do you have a backup of that directory? Then recover the copy and be done.

Oh yes, always have multiple backups of security related keys, ~/.ssh and ~/.gnupg -- just in case something like this happens. Also use the same gpg keys on each box (so I have 5+ working copies of the ~/.gnupg directory) I always wince a bit with just restoring a moving on. Perhaps it is a bit anal-retentive, but I usually want to find out what went wrong so I can either fix it or bug it. I have a lingering suspicion that Tbird is to blame. In not being "shut down" from at least the desktop standpoint, it likely generated a new agent-key (or similar) when it restarted after power was restored and may have used a cached set of key information that was created with a different agent-key, so when things were finally written the agent-key mismatch resulted in key corruption. The keyrings show changes on 2/22 and 2/23 where there were no actual changes made to any key. So something went haywire. Will continue to look at the issue as time permits. Right now, things are restored and I'll be done with it -- for now :) -- David C. Rankin, J.D.,P.E.

On 2/24/21 3:22 PM, Carlos E. R. wrote:

...

I have a lingering suspicion that Tbird is to blame. In not being "shut down" from at least the desktop standpoint, it likely generated a new agent-key (or similar) when it restarted after power was restored and may have used a cached set of key information that was created with a different agent-key, so when things were finally written the agent-key mismatch resulted in key corruption. AFAIK, the agent reads, does not write.

The old Thunderbird has a tool to manage and write the keys, but it is not the agent.

Yep, I have no idea what the right terminology is for the reader and writer of keys and the thing it hashes with -- so whatever you call that thing that gets generated to help protect the actual key data between sessions -- I suspect that thing and the way tbird didn't shut down likely led to the issue. I don't know what part writes the key data back to ~/.gnupg, but from the directory listing -- something is doing it. When I get smart enough to find out what that is -- I'll fill in the blanks. (if someone else knows -- feel free to chime it :) -- David C. Rankin, J.D.,P.E.