GNOME Bugzilla – Bug 691080
Don't try connecting / refreshing mail, calendars and contacts while on a captive network portal
Last modified: 2021-05-19 11:37:30 UTC
From bug #684953, I learned that NetworkManager has a very nice feature allowing you to detect network states where you're behind a captive portal and can't yet access the interwebs. I doubt Evolution uses this already, but if not, it should. It would rock not to have Evolution spamming about failed connection attempts while I haven't yet authenticated to the network. This might also make bug #437659 obsolete. See also: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=267bc993a710ec3923b6f243cb6a4b047fa49ec4
As of 3.6 we don't listen directly to NetworkManager anymore and I don't plan to bring that back. But I do plan to add per-account online/offline state by way of g_network_monitor_can_reach().
I was hunting for this functionality, and found this bug. So I won't make a new one :). I'm currently seeing e-d-s try to connect to my OwnCloud server and getting invalid SSL certificate errors (because of the captive portal's MITM). Whatever test is implemented for this feature - or an additional test - should ideally detect captive-portal in a way that causes it to not try to connect to the MITM'd host, or be accompanied by additional logic to somehow detect the difference between a captive portal SSL intercept and a real SSL cert change. Also, it looks like GNetworkMonitor will someday gain captive portal support, see bug 664562.
Tanks for a bug report. I see the GNetworkMonitor changes landed for GLib 2.44. Quote from the documentation of g_network_monitor_get_connectivity(): > Note that in the case of G_NETWORK_CONNECTIVITY_LIMITED and > G_NETWORK_CONNECTIVITY_PORTAL, it is possible that some sites are reachable > but others are not. In this case, applications can attempt to connect to > remote servers, but should gracefully fall back to their "offline" behavior > if the connection attempt fails. From that, I'd say, instead of asking to accept the certificate, it should just fail with an error message? I'm wondering whether anyone would be willing to accept the MITM state and get to his/her server anyway, because adding some logic to "fail on start, but let the user override the failure by allowing the MITM anyway" would be unnecessary complicated, from my point of view, both in the code and for the users in general.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/evolution/-/issues/ Thank you for your understanding and your help.