Project

General

Profile

Bug #10526

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

Added by intrigeri over 3 years ago. Updated over 3 years ago.

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

100%

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

Description

This ticket is about ensuring this functionality is disabled in Tails 2.0. For research about potentially using such functionality, see #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)".


Related issues

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

History

#1 Updated by intrigeri over 3 years ago

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

#4 Updated by intrigeri over 3 years ago

  • 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 over 3 years ago

  • 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

Also available in: Atom PDF