Bug #10526

Make sure that GNOME 3.14's captive portal handling is disabled on Tails/Jessie

Added by intrigeri 2015-11-10 01:47:55 . Updated 2015-11-10 02:18:10 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Tails_2.0
Start date:
2014-09-26
Due date:
% Done:

100%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Deliverable for:
269

Description

This ticket is about ensuring this functionality is disabled in Tails 2.0. For research about potentially using such functionality, see Bug #7950, its parent ticket and blueprint.

See https://help.gnome.org/misc/release-notes/3.14/. It might be good for us, but it might as well be dangerous and in need to be disabled.

This is implemented via the “connectivity” feature, see e.g. contrib/fedora/rpm/20-connectivity-fedora.conf in NM’s Git tree to see what kind of parameters it can take: basically, it just calls home via a HTTP request, and checks if it gets the expected response — see NetworkManager.conf(5) for details.

It also seems that another component of this feature (the “login agent”) was implemented in GNOME Shell (see https://bugzilla.gnome.org/show_bug.cgi?id=609870, that gives a little bit more details); see e.g. grep -iE (connectivity|portal) in Jessie’s GNOME Shell source => we should have a close look there too. Frederic Peters wrote that “Up in the stack GNOME Shell will automatically popup a window embedding a webkit widget set on the given URI (and thus, displaying the captive portal)”.

Subtasks

Related issues

Copied from Tails - Bug #7950: Consider using GNOME's captive portal handling Confirmed 2014-09-26

History

#1 Updated by intrigeri 2015-11-10 01:47:56

  • copied from Bug #7950: Consider using GNOME's captive portal handling added

#2 Updated by intrigeri 2015-11-10 01:48:16

  • blocks #8668 added

#3 Updated by intrigeri 2015-11-10 01:48:39

  • Deliverable for set to 269

#4 Updated by intrigeri 2015-11-10 02:06:36

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 20

This functionality is enabled at build time on Jessie, but seems to be disabled by default unless explicitly configured in config files. To verify that it’s indeed disabled, set debug level logs for the CONCHECK domain (nmcli g log level DEBUG domains CONCHECK or via NetworkManager.conf) and then force a check with nmcli networking connectivity check.

#5 Updated by intrigeri 2015-11-10 02:18:10

  • Status changed from In Progress to Resolved
  • Assignee deleted (intrigeri)
  • % Done changed from 20 to 100

> […] and then force a check with nmcli networking connectivity check.

On Jessie, this prints “full” and returns immediately (too fast to have done a HTTP request over Tor, no blocked packet in the firewall logs, and I could see no circuit built with Vidalia). I think that’s good enough to confirm that indeed this functionality is opt-in, as documented.

And on sid, I see:

NetworkManager[3810]: <debug> [1447149632.670179] [nm-connectivity.c:317] nm_connectivity_check_async(): connectivity: check: faking request. Connectivity check disabled