Using "Manually copy..." documentation to copy GnuPG folder hides persistent public keyring created in Tails 2.x
on a fresh Tails 3.0 installation, /live/persistence/TailsData_unlocked/gnupg/pubring.kbx and /live/persistence/TailsData_unlocked/gnupg/pubring.kbx~ is created. Older versions of GPG named the public keyring file pubring.gpg. As a result, following https://tails.boum.org/doc/first_steps/persistence/copy/ fails because pubring.kbx is not overwriten, therefore, gpg use it by default and make the user believe that her/his keyring disappeared. It also causes seahorse to be really slow.
I tried with two different usb sticks, both installed from ISO with Tails installer on Debian Sid.
rm -rf pubring.kbx* solved the problem for me.
I don't know if it is the documentation or gpg's configuration that needs to be modified.
#2 Updated by intrigeri about 2 years ago
- Subject changed from Using "Manually copy..." documentation to copy GnuPG folder fails in some cases to Using "Manually copy..." documentation to copy GnuPG folder hides persistent public keyring created in Tails 2.x
- Assignee changed from intrigeri to goupille
- QA Check set to Info Needed
Wow, good catch, thanks!
This will only affect people copying a persistent volume created in Tails 2.x to a Tails 3.x stick. So either we fix this very soon, or it's not worth it. So let's try to prioritize this sensibly, starting with: how often was this reported to help desk?
One way to solve this would be to have
pubring.gpg when it's newer than
pubrink.kbx. Or, we could document that one shall do this manually after rebooting into Tails 3.x with the copied persistent data.
#4 Updated by intrigeri almost 2 years ago
- Status changed from Confirmed to Rejected
- Assignee deleted (
- QA Check deleted (
So either we fix this very soon,
This could not possibly happen with a 2 months latency to get info from help desk.
or it's not worth it.
Let's forget it then.