Tails

#1 Updated by intrigeri 2015-03-22 14:42:11

• blocks #8538 added

#3 Updated by kytv 2015-04-12 23:13:50

• File seahorse.png added
• Status changed from Confirmed to In Progress

When seahorse fails to fetch a key the result can be the following:

I’m not sure how this should be addressed. Maybe clicking on the original window will unlock the second one, so perhaps the FindFailed could be rescued to workaround this Seahorse bug which I think is caused by transient network problems, similiar to

Scenario: Fetching OpenPGP keys using GnuPG should work and be done over Tor.           # features/torified_gnupg.feature:20
    When I fetch the "10CC5BC7" OpenPGP key using the GnuPG CLI                           # features/step_definitions/torified_gnupg.rb:26
      Command failed: gpg --batch  --recv-key '10CC5BC7'
      error code: 2
      stderr: gpg: requesting key 0x10CC5BC7 from hkps server hkps.pool.sks-keyservers.net
      gpg: no valid OpenPGP data found.
      gpg: Total number processed: 0
      .
      <false> is not true. (Test::Unit::AssertionFailedError)
      ./features/support/helpers/misc_helpers.rb:9:in `assert_vmcommand_success'
      ./features/support/helpers/vm_helper.rb:348:in `execute_successfully'
      ./features/step_definitions/torified_gnupg.rb:33:in `/^I fetch the "([^"]+)" OpenPGP key using the GnuPG CLI( without any signatures)?$/'
      features/torified_gnupg.feature:21:in `When I fetch the "10CC5BC7" OpenPGP key using the GnuPG CLI'

and Seahorse isn’t dealing with it properly, appearing to freeze instead of displaying something like “Retrieving key failed: Timeout”.

I’m looking for other cases, like the one intrigeri noted at Bug #9095#note-2

#4 Updated by kytv 2015-04-14 01:23:43

• % Done changed from 0 to 40

#5 Updated by kytv 2015-04-15 21:52:28

• blocked by Bug #9233: Seahorse's configured keyservers are not the same as those in gpg.conf added

#6 Updated by kytv 2015-04-18 11:14:34

• blocked by Bug #9258: Accessing systray icons in the test suite is fragile added

#8 Updated by kytv 2015-04-18 17:51:48

• Assignee changed from kytv to anonym
• QA Check set to Ready for QA
• Feature Branch set to kytv:bugfix/9095-seahorse-robustness

Note: Bug #9233 isn’t strictly needed for this branch but an ISO with it applied will help avoid the ‘greyed out’ problem from Bug #9095#note-3.

#9 Updated by anonym 2015-04-22 10:04:56

• Assignee changed from anonym to kytv
• QA Check changed from Ready for QA to Info Needed

It’s unclear to me what of the reported issues your proposed branch is supposed to fix. I’ve run torified_gnupg.feature multiple times with this branch checked out, on a recent stable build (so Bug #9233 is solved in it) and I’ve still seen a lot of errors. I’d say the probability for me to run the complete feature without any issue is about 50%. Here are the issues I’ve seen:

Seahorse fails to search

  Scenario: Fetching OpenPGP keys using Seahorse via the Tails OpenPGP Applet should work and be done over Tor. # features/torified_gnupg.feature:30
[...]
    When I fetch the "10CC5BC7" OpenPGP key using Seahorse via the Tails OpenPGP Applet                         # features/step_definitions/torified_gnupg.rb:98
      FindFailed: can not find SeahorseFoundKeyResult.png on the screen.
      Line ?, in File ? (RuntimeError)
      features/torified_gnupg.feature:31:in `When I fetch the "10CC5BC7" OpenPGP key using Seahorse via the Tails OpenPGP Applet'

There’s a Seahorse error prompt saying “The search for keys failed. Couldn’t communicate with server ‘pool.sks-keyservers.net’: cannot connect to destination (pool.sks-keyservers.net)”

Seahorse fails to import

  Scenario: Fetching OpenPGP keys using Seahorse via the Tails OpenPGP Applet should work and be done over Tor. # features/torified_gnupg.feature:30
[...]
    Then the "10CC5BC7" key is in the live user's public keyring after at most 120 seconds                      # features/step_definitions/torified_gnupg.rb:51
      The '10CC5BC7' key is not in the live user's public keyring (RuntimeError)
      ./features/support/helpers/misc_helpers.rb:22:in `try_for'
      ./features/step_definitions/torified_gnupg.rb:53:in `/^the "([^"]+)" key is in the live user's public keyring after at most (\d+) seconds$/'
      features/torified_gnupg.feature:32:in `Then the "10CC5BC7" key is in the live user's public keyring after at most 120 seconds'

There’s a Seahorse error prompt saying “Couldn’t import keys. Couldn’t communicate with server ‘pool.sks-keyservers.net’: cannot connect to destination (pool.sks-keyservers.net)”

gpg fails to resolve hkps.pool.sks-keyservers.net

  Scenario: Syncing OpenPGP keys using Seahorse should work and be done over Tor.         # features/torified_gnupg.feature:34
[...]
    Given I fetch the "10CC5BC7" OpenPGP key using the GnuPG CLI without any signatures   # features/step_definitions/torified_gnupg.rb:26
      Command failed: gpg --batch --keyserver-options import-clean --recv-key '10CC5BC7'
      error code: 2
      stdout: gpgkeys: HTTP fetch error 6: Couldn't resolve host name

      stderr: gpg: requesting key 0x10CC5BC7 from hkps server hkps.pool.sks-keyservers.net
      gpg: no valid OpenPGP data found.
      gpg: Total number processed: 0
      .
      <false> is not true. (Test::Unit::AssertionFailedError)
      ./features/support/helpers/misc_helpers.rb:9:in `assert_vmcommand_success'
      ./features/support/helpers/vm_helper.rb:348:in `execute_successfully'
      ./features/step_definitions/torified_gnupg.rb:34:in `/^I fetch the "([^"]+)" OpenPGP key using the GnuPG CLI( without any signatures)?$/'
      features/torified_gnupg.feature:35:in `Given I fetch the "10CC5BC7" OpenPGP key using the GnuPG CLI without any signatures'

Seahorse segfaults :S

calling as root: pidof -x -o '%PPID' seahorse
call returned: [0, "5732\n", ""]
[log] CLICK on (467,114)
[log] CLICK on (307,142)
[log] CLICK on (305,198)
[log] Alt+TYPE "s"
    And I synchronize keys in Seahorse                                                                                  # features/step_definitions/torified_gnupg.rb:85
      FindFailed: can not find SeahorseWindow.png on the screen.
      Line ?, in File ? (RuntimeError)
      features/torified_gnupg.feature:53:in `And I synchronize keys in Seahorse'

From syslog:

[  273.592932] seahorse[5732]: segfault at 0 ip 000000000808c962 sp 00000000ffa401a0 error 4 in seahorse[8048000+bd000]

Let’s ignore this for now.

gpg gnutls_handshake() failure

  Scenario: Syncing OpenPGP keys using Seahorse should work and be done over Tor.         # features/torified_gnupg.feature:34
[..]
calling as amnesia: gpg --batch --keyserver-options import-clean --recv-key '10CC5BC7'
call returned: [2, "gpgkeys: HTTP fetch error 35: gnutls_handshake() failed: A TLS fatal alert has been received.\n", "gpg: requesting key 0x10CC5BC7 from hkps server hkps.pool.sks-keyservers.net\ngpg: no valid OpenPGP data found.\ngpg: Total number processed: 0\n"]
    Given I fetch the "10CC5BC7" OpenPGP key using the GnuPG CLI without any signatures   # features/step_definitions/torified_gnupg.rb:26
      Command failed: gpg --batch --keyserver-options import-clean --recv-key '10CC5BC7'
      error code: 2
      stdout: gpgkeys: HTTP fetch error 35: gnutls_handshake() failed: A TLS fatal alert has been received.

      stderr: gpg: requesting key 0x10CC5BC7 from hkps server hkps.pool.sks-keyservers.net
      gpg: no valid OpenPGP data found.
      gpg: Total number processed: 0
      .
      <false> is not true. (Test::Unit::AssertionFailedError)
      ./features/support/helpers/misc_helpers.rb:9:in `assert_vmcommand_success'
      ./features/support/helpers/vm_helper.rb:348:in `execute_successfully'
      ./features/step_definitions/torified_gnupg.rb:34:in `/^I fetch the "([^"]+)" OpenPGP key using the GnuPG CLI( without any signatures)?$/'
      features/torified_gnupg.feature:35:in `Given I fetch the "10CC5BC7" OpenPGP key using the GnuPG CLI without any signatures'

Running the command again quickly after the error (via features/scripts/vm-execute) reproduces it but waiting a few minutes fixes it. This makes me think at least one of the pool members has some issue, but I manually tried each pool member (by IP address), and didn’t see the issue, and even re-resolved multiple times to get other pool members. Not sure what to make of this.

Thoughts

Ignoring the segfault, to me it seems like pool.sks-keyservers.net isn’t working very well, not that the tests are poor (at least with the fixes from your branch). How do these tests behave for you?

#10 Updated by kytv 2015-04-22 12:25:57

• Assignee changed from kytv to anonym

anonym wrote:
> It’s unclear to me what of the reported issues your proposed branch is supposed to fix.

There were three (main) reported problems which I was able to reproduce.

1. Greyed out seahorse, probably taken care of for real by Bug #9233 but also mitigated by 8b906f31f080
2. Failing to open the Preferences in order to enable synchronization (addressed by 3e91a8961f6211a63)
3. Occasionally failing to search for Keys (both in the original tests which I had nothing to do with, and in the new test in which Seahorse is started from the gpgApplet). This was likely fixed by Bug #9233.

While running (and running (and running)) this scenario I stumbled upon another failure when trying to sync or find keys. I think that this could have been mitigated with introducing a static sleep or two, but I opted for clicking through the menus.

> h3. Thoughts
>
> Ignoring the segfault, to me it seems like pool.sks-keyservers.net isn’t working very well, not that the tests are poor (at least with the fixes from your branch). How do these tests behave for you?

Unfortunately it’s about the same for me. When pool.sks-keyservers.net is functioning properly these tests work flawlessly; when it seems to be having “issues” I can see similar results caused by some sort of instability with pool.sks-keyservers.net. 4-5 days ago I didn’t have any problems. Today, OTOH, after a couple of runs I saw

stdout: gpgkeys: HTTP fetch error 35: gnutls_handshake() failed: A TLS fatal alert has been received.

once and

> There’s a Seahorse error prompt saying “Couldn’t import keys. Couldn’t communicate with server ‘pool.sks-keyservers.net’: cannot connect to destination (pool.sks-keyservers.net)”

once as well.

With this branch the tests themselves are (IMHO) fine.

#12 Updated by kytv 2015-05-03 10:47:38

• QA Check changed from Info Needed to Ready for QA

<intrigeri> KillYourTV: https://labs.riseup.net/code/issues/9095 should be ready for QA, or?

Yes, Probably so.

intrigeri wrote:
> I’ve seen that one again while testing 1.4~rc1:
>
> […]
>
> Is it supposed to be fixed by the proposed (but not merged yet) branch?

If it was caused by a transient error, such as the one anonym referenced above, no.

anonym wrote:
> There’s a Seahorse error prompt saying “Couldn’t import keys. Couldn’t communicate with server ‘pool.sks-keyservers.net’: cannot connect to destination (pool.sks-keyservers.net)”

If we are to work around transient errors like this we’ve got a bit of work to do everywhere.

#14 Updated by anonym 2015-05-05 14:15:01

• Assignee changed from anonym to kytv
• Target version changed from Tails_1.4 to Tails_1.4.1
• QA Check changed from Ready for QA to Dev Needed

intrigeri wrote:
> > intrigeri wrote:
> >> I’ve seen that one again while testing 1.4~rc1:
> >> […]
> >> Is it supposed to be fixed by the proposed (but not merged yet) branch?
>
> > If it was caused by a transient error, such as the one anonym referenced above, no.
>
> The way I understand this error, it seems to happen before any attempt to fetch keys, so I don’t think it can be caused by a transient networking or keyserver pool error.

You are correct.

> Note that this is the first error reported in this ticket’s description, hence my question: it would be a problem to mark it as fixed, if it’s not. Now, if the rest is fixed but this one isn’t, then it can be moved to a dedicated ticket of course :)

Right. Still, the current branch improves things, and it solves one problem => opened Bug #9343, had KillYourTV quickly rewrite the commit messages for that new ticket, and merged it. Still, some issues remain (will open subtickets), but they won’t be solved for Tails 1.4. Post-poning to Tails 1.4.1.

#15 Updated by anonym 2015-05-05 14:16:40

• Feature Branch deleted (kytv:bugfix/9095-seahorse-robustness)

#21 Updated by kytv 2015-06-29 00:12:33

• Target version changed from Tails_1.4.1 to Tails_1.5

Will be mostly resolved by Feature #9518.

#22 Updated by kytv 2015-08-02 11:00:34

• Assignee deleted (kytv)
• QA Check deleted (Dev Needed)

This ticket still has subtasks which are open but I don’t think “Seahorse tests lack robustness” is true anymore.

Now that we are retrying when communicating with the keyservers fails the torified_gnupg feature is stable. Indeed, I don’t see it fail anymore, other than the (thankfully) rare times in which Seahorse segfaults :|.

Should this ticket perhaps be closed?

#23 Updated by intrigeri 2015-08-03 04:29:46

• Assignee set to kytv

> This ticket still has subtasks which are open but I don’t think “Seahorse tests lack robustness” is true anymore.

If the remaining subtasks don’t imply lack of robustness, then they should not be children of this ticket ⇒ please fix that.

> Indeed, I don’t see it fail anymore, other than the (thankfully) rare times in which Seahorse segfaults :|.

I suggest making the ticket that tracks said segfaults a subtask of this one.

> Should this ticket perhaps be closed?

Now that you’ve pointed to another open robustness issue, I don’t think so.

#24 Updated by kytv 2015-08-11 07:59:08

• blocked by Bug #9970: Seahorse may segfault during key synchronization added

#25 Updated by kytv 2015-08-11 10:35:35

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

#26 Updated by kytv 2015-09-22 03:49:31

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

#28 Updated by kytv 2015-11-04 10:46:04

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

#29 Updated by kytv 2015-11-06 10:53:13

• related to Bug #10500: Monitor failure modes of Seahorse added

#31 Updated by kytv 2015-11-13 13:19:08

• Assignee changed from kytv to anonym
• QA Check set to Ready for QA
• Feature Branch set to kytv/test/9095-robust-seahorse

I made quite a few changes here. After several days of running this feature both in wheezy (and with it merged into feature/jessie for Bug #9791) it’s been robust without any failures.

I really hope Jenkins will be happy with this but we’ll see…

#34 Updated by intrigeri 2015-12-05 13:32:34

• Assignee changed from anonym to bertagaz

#35 Updated by intrigeri 2015-12-05 13:43:19

• Assignee changed from bertagaz to intrigeri

I’ll take Bug #9791 and check this one.

#36 Updated by intrigeri 2015-12-07 11:50:47

• blocks deleted (Bug #9970: Seahorse may segfault during key synchronization)

#37 Updated by intrigeri 2015-12-07 11:51:49

• related to Bug #9970: Seahorse may segfault during key synchronization added

#38 Updated by intrigeri 2015-12-07 12:42:23

• Status changed from In Progress to Fix committed

Applied in changeset commit:9f0692b76f00c6a46b110b8aa6400be02e283067.

#39 Updated by intrigeri 2015-12-07 12:43:31

• Assignee deleted (intrigeri)
• QA Check changed from Ready for QA to Pass

#40 Updated by anonym 2015-12-16 11:32:56

• Status changed from Fix committed to Resolved