Bug #15014

Keys disappear from Seahorse after importing one

Added by mercedes508 2017-12-04 09:59:30 . Updated 2019-04-05 13:18:01 .

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

0%

Feature Branch:
Type of work:
Communicate
Blueprint:

Starter:
Affected tool:
Deliverable for:

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.

Subtasks

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 2017-06-29
Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed

History

#1 Updated by goupille 2017-12-15 17:30:48

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

it was also reported by an anonymous user.

#2 Updated by intrigeri 2017-12-24 09:10:58

  • 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 Bug #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 2018-01-01 16:27:17

  • 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 2018-01-02 09:01:11

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 2018-01-02 09:03:31

  • 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 2018-01-02 18:10:09

  • 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 2018-01-03 09:16:47

  • 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 2018-01-03 15:06:13

  • 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 2018-01-03 15:47:37

  • 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 2018-01-04 17:35:59

  • 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 2018-01-04 18:34:52

  • 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 2018-01-23 19:52:53

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

#14 Updated by bertagaz 2018-03-14 11:32:27

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

#15 Updated by goupille 2018-04-05 17:18:32

  • 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 2018-04-14 09:34:44

  • 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 2018-04-30 15:39:33

  • 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 2018-04-30 15:54:09

  • 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 2018-04-30 16:55:20

  • 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 2018-05-05 13:24:24

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

#21 Updated by sajolida 2018-05-09 07:19:35

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 2018-05-29 08:25:21

  • 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 2018-05-29 08:51:35

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 2018-05-29 08:51:43

#25 Updated by intrigeri 2018-06-16 08:32:04

goupille, ping?

#26 Updated by goupille 2018-06-19 13:02:34

  • 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 2018-06-19 16:28:48

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

#28 Updated by intrigeri 2018-06-28 14:26:58

  • blocked by deleted (Feature #15139: Core work 2018Q2: Foundations Team)

#29 Updated by intrigeri 2018-06-28 14:27:01

#30 Updated by intrigeri 2018-08-15 19:25:06

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

#31 Updated by Anonymous 2018-08-16 13:18:38

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

#32 Updated by intrigeri 2018-10-08 13:57:59

#33 Updated by intrigeri 2018-10-08 13:58:02

  • blocked by deleted (Feature #15334: Core work 2018Q3: Foundations Team)

#34 Updated by intrigeri 2018-10-08 14:42:06

  • QA Check set to Info Needed

Next steps: forward bug reports & debugging info to hefee and reassign to them.

#35 Updated by intrigeri 2018-10-12 13:39:48

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

intrigeri wrote:
> Next steps: forward bug reports & debugging info to hefee and reassign to them.

Done!

#36 Updated by intrigeri 2018-10-24 17:03:43

  • Target version changed from Tails_3.10.1 to Tails_3.11

#37 Updated by hefee 2018-11-26 09:53:12

  • Estimated time set to 0 h

I see that we can have different sources for this bug:

  • a migration issue between gnupg2 and gnupg. I saw it serveral times, that gpg related tools do not handle GnuPG 2 files correctly and do wired things with the old GnuPG 1 files or vise versa. Does we see this truncated list of keys also if we use gpg2 in cmdline? What is the output of:

gpg2 --debug-all -k

  • the imported key has one feature that triggers the issue.
    -> can someone send an fingerprint on the Keyserver, that triggered the issue?
    With that we hopefully can locate the issue to either GnuPG, the used libs or seahorse.

#38 Updated by intrigeri 2018-11-26 11:07:33

> * a migration issue between gnupg2 and gnupg. I saw it serveral times, that gpg related tools do not handle GnuPG 2 files correctly and do wired things with the old GnuPG 1 files or vise versa.

Agreed, that’s a plausible explanation.

> Does we see this truncated list of keys also if we use gpg2 in cmdline? What is the output of: gpg2 --debug-all -k

gpg points to gpg2 on Stretch so I think that the output I’ve sent you is exactly what you’re asking.

> * the imported key has one feature that triggers the issue.
> -> can someone send an fingerprint on the Keyserver, that triggered the issue?
> With that we hopefully can locate the issue to either GnuPG, the used libs or seahorse.

Good idea. In order to ask this extra info to the OP, I think you’ll need to help them a bit by telling them which exact key/fingerprint you’re interested into.

#39 Updated by hefee 2018-11-28 14:50:16

intrigeri wrote:
> > Does we see this truncated list of keys also if we use gpg2 in cmdline? What is the output of: gpg2 --debug-all -k
>
> gpg points to gpg2 on Stretch so I think that the output I’ve sent you is exactly what you’re asking.

right gpg2 is a symlink to gpg, so this should not make any difference. Okay on thing less to test :D
>
> > * the imported key has one feature that triggers the issue.
> > -> can someone send an fingerprint on the Keyserver, that triggered the issue?
> > With that we hopefully can locate the issue to either GnuPG, the used libs or seahorse.
>
> Good idea. In order to ask this extra info to the OP, I think you’ll need to help them a bit by telling them which exact key/fingerprint you’re interested into.

Something like that:

Next time this happens, please try to reproduce it:

  1. Save the key you wanted to import / write down the fingerprint.
  2. Restart tails WITHOUT persistance enabled
  3. Check keylisting from Seahorse
  4. Import the saved key again at this session
  5. Is Seahorse broken?
  6. Report back from this experiment via WhisperBack. If you add the key/fingerprint you have imported, than we may reproduce the issue on ourselves.

#40 Updated by hefee 2018-11-28 14:50:55

  • Estimated time changed from 0 h to 1 h

#41 Updated by hefee 2018-12-02 10:56:26

  • Estimated time changed from 1 h to 2 h

#42 Updated by hefee 2018-12-03 15:44:59

  • Target version changed from Tails_3.11 to Tails_3.12

i don’t have inpurt - so nothing to fix.

#43 Updated by intrigeri 2018-12-03 16:27:27

> i don’t have inpurt - so nothing to fix.

As discussed at the FT meeting today, this input must be requested from the user who reported the bug and provided debug info. hefee will try to find their email address and if that does not work, I will.

#44 Updated by hefee 2018-12-07 19:25:15

  • Assignee changed from hefee to intrigeri

> As discussed at the FT meeting today, this input must be requested from the user who reported the bug and provided debug info. hefee will try to find their email address and if that does not work, I will.

Okay I found the e-mail addresses, but I dislike to send a response from my personal emailadresse. Is there a solution to send those responses from a tails related emailadress?

#45 Updated by intrigeri 2018-12-08 08:48:24

> Okay I found the e-mail addresses, but I dislike to send a response from my personal emailadresse. Is there a solution to send those responses from a tails related emailadress?

Replied in the other place where you asked the same question.

#46 Updated by intrigeri 2018-12-08 08:48:34

  • Assignee changed from intrigeri to hefee

#47 Updated by hefee 2018-12-10 13:53:37

mail is finally sent to reporter to ask for more details.

#48 Updated by hefee 2019-01-04 10:02:35

  • blocked by deleted (Feature #15506: Core work 2018Q4: Foundations Team)

#49 Updated by hefee 2019-01-04 10:03:37

#50 Updated by hefee 2019-01-04 15:44:50

  • Target version changed from Tails_3.12 to Tails_3.13

Lets postpone, as we wait for input from user.

#51 Updated by hefee 2019-02-06 11:37:47

  • blocked by deleted (Feature #15507: Core work 2019Q1: Foundations Team)

#52 Updated by intrigeri 2019-02-06 18:03:20

> Blocks deleted (Feature Feature #15507: Core work 2019Q1: Foundations Team)

Can you please explain?

#53 Updated by hefee 2019-02-08 15:22:34

intrigeri wrote:
> > Blocks deleted (Feature Feature #15507: Core work 2019Q1: Foundations Team)
>
> Can you please explain?

As I’m waiting for new input - I don’t know, when I’ll come back to that issue. And it doesn’t looks like FT will do own research on that issue. As it is still assigned to me I’ll readd it to Core work if we get input again. I just wants to keep the FT Core work view clean.

#54 Updated by Anonymous 2019-02-08 15:34:06

hefee wrote:
> intrigeri wrote:
> > > Blocks deleted (Feature Feature #15507: Core work 2019Q1: Foundations Team)
> >
> > Can you please explain?
>
> As I’m waiting for new input - I don’t know, when I’ll come back to that issue. And it doesn’t looks like FT will do own research on that issue. As it is still assigned to me I’ll readd it to Core work if we get input again. I just wants to keep the FT Core work view clean.

I think the idea of the “Blocking” relationship is to not forget that this was budgeted for Core work and allow others in the project to see which things are taken care of. If you take it out of the view, everyone else loses track of it.

#55 Updated by intrigeri 2019-02-18 17:53:47

#56 Updated by intrigeri 2019-02-18 18:02:11

  • Type of work changed from Research to Communicate

Hi hefee!

You’re right that we won’t research nor fix this bug ourselves. The best outcome we can expect here at this point is: enough info to reproduce the bug and report it to Debian or upstream. I’m adjusting “Type of work” to better reflect what’s the expectation at this point.

Ulrike is correct: keeping this on the FT view is useful for the reasons she mentioned… and also 1. so that you can bill your work; 2. to make the expectations clear here (this is paid work, not volunteer work, and it comes with different expectations).

You’ve asked info to the user 2 months ago. It makes little sense to wait indefinitely so please ping them once, and then if they don’t reply within a month or so, reject this ticket as “not enough info for us to do anything about it”. Pinging & keeping track of replies is part of the communication work here; this does not happen magically for free, it’s FT work, hence I’ve re-added the blocking relationship.

I hope that with these clarifications, the Redmine semantics make better sense to you :)

Cheers!

#57 Updated by hefee 2019-02-20 14:51:24

I’ll pinged the person again. Let’s wait till end of March (end of QI) and than reject this issue.

#58 Updated by intrigeri 2019-03-12 14:17:28

  • Target version changed from Tails_3.13 to Tails_3.14

Great!

#59 Updated by intrigeri 2019-03-20 14:46:03

#60 Updated by intrigeri 2019-03-20 14:46:15

  • blocked by deleted (Feature #15507: Core work 2019Q1: Foundations Team)

#61 Updated by intrigeri 2019-04-05 13:18:01

  • Status changed from Confirmed to Rejected
  • Assignee deleted (hefee)
  • Target version deleted (Tails_3.14)

In a year we never managed to get enough debugging info to report this upstream.