Project

General

Profile

Bug #15014

Keys disappear from Seahorse after importing one

Added by mercedes508 10 months ago. Updated about 1 month ago.

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
12/04/2017
Due date:
% Done:

0%

QA Check:
Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:

Description

I've encountered the following issue several times with seahorse from Tails 3.2, 3.3 at least:

when importing a key, either from desktop or from keyservers, then all my keys disappear from seahorse. Keys are still there but to have them back I have to delete the following files:

  • .gpg-v21-migrated
  • pubring.kbx

I can send relevant logs if needed.


Related issues

Related to Tails - Bug #13251: Using "Manually copy..." documentation to copy GnuPG folder hides persistent public keyring created in Tails 2.x Rejected 06/29/2017
Blocks Tails - Feature #15334: Core work 2018Q3: Foundations Team Confirmed 02/20/2018

History

#1 Updated by goupille 9 months ago

It looks a lot like https://labs.riseup.net/code/issues/13251

it was also reported by an anonymous user.

#2 Updated by intrigeri 9 months ago

  • Subject changed from Keys disappear from seahorse after importing one to Keys disappear from Seahorse after importing one
  • Assignee changed from intrigeri to mercedes508
  • QA Check set to Info Needed

goupille wrote:

It looks a lot like https://labs.riseup.net/code/issues/13251

Absolutely: the behaviour and immediate technical explanation are the same (pubring.kbx lacks keys for some reason, while they're still in pubring.gpg). But #13251 was well understood and happened only in a very specific case, while I've seen this one happen a few times to several Tails contributors who (I think) did not follow https://tails.boum.org/doc/first_steps/persistence/copy/.

Next time you see this happen please send me the output of ls -lA ~/.gnupg/ and a WhisperBack report, both generated immediately after the problem is identified, during the same session, and before doing anything else with GnuPG.

mercedes508: can you reproduce this reliably, or does it happen seemingly randomly?

#3 Updated by mercedes508 9 months ago

  • Assignee changed from mercedes508 to intrigeri

Hi,

Next time you see this happen please send me the output of ls -lA ~/.gnupg/ and a WhisperBack report, both generated immediately after the problem is identified, during the same session, and before doing anything else with GnuPG.

Done :)

mercedes508: can you reproduce this reliably, or does it happen seemingly randomly?

It seems quite random as I imported a few keys today and everything went fine for a couple of them until I got the error.

#4 Updated by intrigeri 9 months ago

Thanks for the report, I'll look into it.

But now I realized my instructions were insufficient. So, next time you see this happen please send me the output of ls -lA --full-time ~/.gnupg/ and a WhisperBack report, both generated immediately after the problem is identified, during the same session, and before doing anything else with GnuPG.

#5 Updated by intrigeri 9 months ago

  • Assignee changed from intrigeri to mercedes508

The WhisperBack bug report you've sent me was truncated. Do you still have access to the full one?

#6 Updated by mercedes508 9 months ago

  • Assignee changed from mercedes508 to intrigeri

intrigeri wrote:

The WhisperBack bug report you've sent me was truncated. Do you still have access to the full one?

I just resent it. I thought I had fixed for ever this thunderbird wrapping issue...

Tell me if it's enough or if I should re-produce this to get the full output of the commandline.

#7 Updated by intrigeri 9 months ago

  • Assignee changed from intrigeri to mercedes508

There's one interesting thing in this bug report: seahorse[17583]: imported key but then couldn't find it in keyring: [erased fingerprint]. This comes either from https://sources.debian.org/src/libcryptui/3.12.2-5/daemon/seahorse-gpgme-source.c/?hl=837#L837 or from https://sources.debian.org/src/seahorse/3.20.0-4/pgp/seahorse-gpgme-keyring.c/?hl=601#L601, most likely the latter as strings can find this error message in /usr/bin/seahorse but not in the libcryptui binary library. Sadly, it does not tell me much apart of confirming what we already knew (pubring.kbx is mostly empty).

Tell me if it's enough or if I should re-produce this to get the full output of the commandline.

Thanks, I think that's enough for now.

Next time this happens, immediately after the problem is identified, during the same session, and before doing anything else with GnuPG, please:

  1. open WhisperBack
  2. run ls -lA --full-time ~/.gnupg/ ~/.gnupg/private-keys-v1.d and copy its output into the bug report
  3. delete .gpg-v21-migrated and pubring.kbx
  4. run gpg -k in a Terminal and copy its output into the bug report
  5. run ls -lA --full-time ~/.gnupg/ ~/.gnupg/private-keys-v1.d again and copy its output into the bug report

You said this happens when importing "either from desktop or from keyservers". Do I understand correctly that:

  • "from desktop" means "by right-clicking on the key file on the desktop and clicking 'Import Key' or whatever it's called"
  • "from keyservers" means "by starting 'Passwords and Keys' and from there fetching the key from keyservers"?

Also, do you ever use Enigmail to manage keys?

Finally, I'd like to find out if the bug is in Seahorse (or the libraries it uses to communicate with GnuPG) or in GnuPG itself. Could you please stop using Seahorse and Enigmail to import keys for a while, and instead always use gpg on the command-line (gpg --import FILE, gpg --recv-keys FINGERPRINT), or is it too much to ask?

#8 Updated by mercedes508 9 months ago

  • Assignee changed from mercedes508 to intrigeri

You said this happens when importing "either from desktop or from keyservers". Do I understand correctly that:

  • "from desktop" means "by right-clicking on the key file on the desktop and clicking 'Import Key' or whatever it's called"
  • "from keyservers" means "by starting 'Passwords and Keys' and from there fetching the key from keyservers"?

Exactly.

Also, do you ever use Enigmail to manage keys?

No, never tried.

Finally, I'd like to find out if the bug is in Seahorse (or the libraries it uses to communicate with GnuPG) or in GnuPG itself. Could you please stop using Seahorse and Enigmail to import keys for a while, and instead always use gpg on the command-line (gpg --import FILE, gpg --recv-keys FINGERPRINT), or is it too much to ask?

No I can try that. But it might takes some time before I need to do it.

#9 Updated by intrigeri 9 months ago

  • Assignee changed from intrigeri to mercedes508

Finally, I'd like to find out if the bug is in Seahorse (or the libraries it uses to communicate with GnuPG) or in GnuPG itself. Could you please stop using Seahorse and Enigmail to import keys for a while, and instead always use gpg on the command-line (gpg --import FILE, gpg --recv-keys FINGERPRINT), or is it too much to ask?

No I can try that. But it might takes some time before I need to do it.

Cool, thanks! So I'm leaving this on your plate because the next action is yours.

#10 Updated by mercedes508 9 months ago

  • Assignee changed from mercedes508 to intrigeri

Cool, thanks! So I'm leaving this on your plate because the next action is yours.

So I just fetched 7 keys from keyservers using gpg as asked above, and didn't get any error. Everything is still in seahorse.

But as this error isn't appearing consistenly I don't know how we should consider this test?

#11 Updated by intrigeri 9 months ago

  • Assignee changed from intrigeri to mercedes508
  • Target version set to Tails_3.5

So I just fetched 7 keys from keyservers using gpg as asked above, and didn't get any error. Everything is still in seahorse.

Thanks!

But as this error isn't appearing consistenly I don't know how we should consider this test?

I think we'll need more long term data before we can draw any conclusion. So please keep using gpg for a few weeks and then we'll see.

#13 Updated by anonym 8 months ago

  • Target version changed from Tails_3.5 to Tails_3.6

#14 Updated by bertagaz 6 months ago

  • Target version changed from Tails_3.6 to Tails_3.7

#15 Updated by goupille 6 months ago

  • Assignee changed from mercedes508 to intrigeri
  • QA Check deleted (Info Needed)

I just sent you the requested info (ticket number in the subject)

#16 Updated by intrigeri 5 months ago

  • Assignee changed from intrigeri to goupille
  • QA Check set to Info Needed

goupille wrote:

I just sent you the requested info (ticket number in the subject)

Thank you. What's relevant in there is:

amnesia@amnesia:~$ gpg -k
gpg: skipped packet of type 8 in keybox
gpg: parse_keyblock_image: signature count does not match
gpg: keydb_get_keyblock failed: Invalid keyring /home/amnesia/.gnupg/pubring.kbx
--------------------------------
pub   rsa4096/0xC436090F4BB47C6F 2014-07-11 [SCEA]
      Key fingerprint = 256D EB90 7788 0CD6 8167  8528 C436 090F 4BB4 7C6F
uid                   [ unknown] Tails accounting team (schleuder list) <tails-accounting@boum.org>
uid                   [ unknown] Tails accounting team (schleuder list) <tails-accounting-request@boum.org>
uid                   [ unknown] Tails accounting team (schleuder list) <tails-accounting-owner@boum.org>
sub   rsa4096/0x289A5B45A9E89475 2014-07-11 [SEA]

pub   rsa4096/0xEC57B56EF0C43132 2013-07-24 [SC] [expires: 2018-07-23]
      Key fingerprint = 1F56 EDD3 0741 0480 35DA  C1C5 EC57 B56E F0C4 3132
uid                   [ unknown] Tails bug squad <tails-bugs@boum.org>
uid                   [ unknown] Tails bug squad (schleuder list) <tails-bugs-request@boum.org>
uid                   [ unknown] Tails bug squad (schleuder list) <tails-bugs-owner@boum.org>
uid                   [ unknown] Tails private user support <tails-support-private@boum.org>
sub   rsa4096/0x9D6D6472AFC1AD77 2013-07-24 [E] [expires: 2018-07-23]

Assuming that output is complete and unredacted (please ask the user about this), from the 7 keys we're supposed to import in source:config/chroot_local-includes/lib/live/config/2000-import-gnupg-key, only the first two ones are listed.

Also, please ask the user:

  • what exact action triggered this problem
  • the full, unredacted output of gpg --debug-all -k
  • was persistent GnuPG enabled and persistence unlocked when this problem happened? if yes, I need the content of ~/.gnupg/gpg.conf

If you have the original full bug report, I need it to see if it has anything to do with https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868550#50.

Searching the web for "keydb_get_keyblock failed: Invalid keyring" shows lots of potentially related issues. At least one of them was fixed in GnuPG 2.1.20 but Stretch has 2.1.18 (+ a bunch of patches) so it might be that Tails 4.0 will fix that for free.

#17 Updated by goupille 5 months ago

  • Assignee changed from goupille to intrigeri

intrigeri, the info you requested was resent to you (with the ticket number in the subject)

#18 Updated by intrigeri 5 months ago

  • Assignee changed from intrigeri to goupille

goupille wrote:

intrigeri, the info you requested was resent to you (with the ticket number in the subject)

Yes (thanks!) and no:

  • the gpg command was run as root, which make its output useless => I've asked the user to send me the requested output
  • I've asked you the original full bug report and I don't think you've sent it to me

#19 Updated by goupille 5 months ago

  • Assignee changed from goupille to intrigeri

intrigeri wrote:

  • I've asked you the original full bug report and I don't think you've sent it to me

sorry, I just did

#20 Updated by intrigeri 5 months ago

  • Target version changed from Tails_3.7 to Tails_3.8

#21 Updated by sajolida 5 months ago

Hey! We're in a meeting with Cody and we were wondering if there was anything we could do as technical writers to help these people. Any idea?

#22 Updated by intrigeri 4 months ago

  • Assignee changed from intrigeri to goupille

goupille wrote:

intrigeri wrote:

  • I've asked you the original full bug report and I don't think you've sent it to me

sorry, I just did

Nope, you've sent me a truncated one.

#23 Updated by intrigeri 4 months ago

I suspect https://dev.gnupg.org/rGb375d50ee4ce52c9b0f0855ec155be027642fb05 (in upstream 2.2.5 and newer) fixes the problem.

On top of what I've asked goupille, I've asked the user to send me more info. Once I have it I can test my hypothesis.

#24 Updated by intrigeri 4 months ago

#25 Updated by intrigeri 3 months ago

goupille, ping?

#26 Updated by goupille 3 months ago

  • Assignee changed from goupille to intrigeri
  • QA Check deleted (Info Needed)

sorry about that, you should have it in your inbox

#27 Updated by intrigeri 3 months ago

  • Target version changed from Tails_3.8 to Tails_3.9

#28 Updated by intrigeri 3 months ago

#29 Updated by intrigeri 3 months ago

#30 Updated by intrigeri about 1 month ago

  • Target version changed from Tails_3.9 to Tails_3.10

#31 Updated by u about 1 month ago

  • Related to Bug #13251: Using "Manually copy..." documentation to copy GnuPG folder hides persistent public keyring created in Tails 2.x added

Also available in: Atom PDF