On 24/02/2021 23.01, David C. Rankin wrote:
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.
There is no need at all for any agent mechanism to write to the private keys data. What "/usr/bin/gpg-agent" (which is not part of Thunderbird) does is cache the password you use when signing something. It doesn't write anything, certainly not to the private keys. Thunderbird has another agent. I can not look it up, my version is current, and you use the old one. But its purpose is the same thing. The only thing in thunderbird that I know can write *one* key is the key management module. And you were not using it.
(if someone else knows -- feel free to chime it :)
-- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)