Bug #10228

CTCP test assumes that we're still using the configured, randomized nickname

Added by kytv 2015-09-21 16:45:36 . Updated 2016-05-10 07:22:26 .

Status:
Rejected
Priority:
Normal
Assignee:
anonym
Category:
Test suite
Target version:
Start date:
2015-09-21
Due date:
% Done:

100%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
0
Affected tool:
Instant Messaging
Deliverable for:
270

Description

The test can fail if the randomized nickname that was generated is already in use.

Received unexpected CTCP reply 'CLIENTINFO' with data 'PING VERSION TIME USERINFO CLIENTINFO'
/home/ky/usr/bin/cucumber:13:in `<main>'er/cli/main.rb:42:in `execute!'sit_features'features'lement'd'e_filtering'
    And the "irc.oftc.net" account only responds to PING and VERSION CTCP requests # features/step_definitions/pidgin.rb:346
      Received unexpected CTCP reply 'CLIENTINFO' with data 'PING VERSION TIME USERINFO CLIENTINFO' (RuntimeError)
      ./features/support/helpers/ctcp_helper.rb:115:in `block in on_message'
      ./features/support/helpers/ctcp_helper.rb:105:in `each'
      ./features/support/helpers/ctcp_helper.rb:105:in `on_message'
      ./features/support/helpers/ctcp_helper.rb:38:in `block in verify_ctcp_responses'
      ./features/support/helpers/ctcp_helper.rb:37:in `verify_ctcp_responses'
      ./features/step_definitions/pidgin.rb:358:in `/^the "([^"]*)" account only responds to PING and VERSION CTCP requests$/'
      features/pidgin.feature:68:in `And the "irc.oftc.net" account only responds to PING and VERSION CTCP requests'

In this case, the nickname which was generated was already on IRC so the nickname in Pidgin in the TailsToaster VM had a 1 tacked on to the end, causing the CTCP test to test a real user. The logs (redacted a bit) showed the following:

D, [2015-09-2xTxx:yy:zz.594006 #8146] DEBUG -- : RECEIVE: :nickname!~xyz@nickname.user.oftc.net NOTICE Asf7sF9ZgF :^ACLIENTINFO PING VERSION TIME USERINFO CLIENTINFO^A


A user connected via Tor in Pidgin would look like nickname!nicknameRANDOMSTRING.tor-irc.dnsbl.oftc.net@.


Subtasks


History

#1 Updated by kytv 2015-09-21 16:48:14

  • Starter set to No

#2 Updated by intrigeri 2015-11-01 03:47:53

  • blocks #8668 added

#3 Updated by intrigeri 2015-11-01 03:48:07

  • Status changed from New to Confirmed
  • Deliverable for set to 270

Looks like this ticket should be a subtask of some robustness parent ticket, or something. I’ll let you folks move it where appropriate.

#4 Updated by intrigeri 2015-11-10 12:01:45

  • Assignee set to anonym
  • Target version set to Tails_2.2

(Tentatively giving an assignee and milestone, so it’s on some radar :)

#5 Updated by anonym 2016-03-07 11:44:41

kytv wrote:
> The test can fail if the randomized nickname that was generated is already in use.

There are primarily (only?) three reasons for this:

  1. the nickname is registered.
  2. the nickname is occupied by another user.
  3. the nickname is occupied by our ghost from the previous scenario (remember, we use snapshots so we’ll have the same nickname).

3 can be solved quite easily with something like this:

When /^I start Pidgin through the GNOME menu$/ do
  step 'I start "Pidgin" via the GNOME "Internet" applications menu'
  # Deal with IRC ghosting and similar by making sure that Pidgin
  # shuts down cleanly.
  add_after_scenario_hook do
      break if not $vm.has_process?('pidgin')
      $vm.execute('killall pidgin')
  end
end

But 1 and 2 are trickier, at least if we want to keep using our randomized nicknames since they do sometimes generate nicknames that are in use (I’m not sure if this is good (i.e. it indicates that the nicknames are believable) or bad (nickname colisions are bad UX) :P). AFAICT we cannot easily query pidgin what the actual nickname we are using is (even the UI makes this a bit hard — AFAIK you need to send a message to be really sure(?)).

I suppose the proper fix for 1 and 2 is to replace the generated nickname with something a lot more random, like the ones we use for the CTCP bot.

#6 Updated by intrigeri 2016-03-08 10:31:47

In passing, Feature #7874 might obsolete this ticket somewhat.

#7 Updated by anonym 2016-03-15 11:22:46

  • Target version changed from Tails_2.2 to Tails_2.3

#8 Updated by anonym 2016-04-20 11:33:01

  • Target version changed from Tails_2.3 to Tails_2.4

#9 Updated by intrigeri 2016-05-10 07:22:26

  • Status changed from Confirmed to Rejected
  • % Done changed from 0 to 100

This will go away with the IRC tests (Feature #11306).