Summary of Thursday's call between GNOME and NM devels and Default DNS resolver change owners

[Chuck Anderson]

Looks great!  I've been using this daily on Fedora 21 and I have to
say it mostly works well EXCEPT for the captive portal detection stuff
which is just horrendously bad, so I'm happy to see a new design that
may work a lot better.

Will the below be substantially implemented and testable
by the July 28 Change CheckPoint: Completion deadline (testable)?
That is only 10 days away...

It would be great if the Change page could be updated with these plans
and the current status, how to test, etc.

Thanks!

On Fri, Jul 17, 2015 at 05:40:56PM +0200, Tomas Hozza wrote:
> Hello all.
> 
> I would like to share the outcome of the discussion between GNOME and NM developers
> and the "Default DNS resolver" [1] Change for F23.
> 
> The full summary can be found here [2] and recording here [3] is anyone is interested.
> 
> 
> Integration points:
> - Captive portal detection
> - Captive portal handling
> - User interaction
> 
> 
> Points we agreed on:
> * Captive portal detecion
>   * NM side
>     * NM will be the only daemon doing Captive portal detection
>     * NM moves connectivity check before NM_DEVICE_STATE_ACTIVATED, emits signal before network is "up"
>     * If portal has been detected, NM blocks NM_DEVICE_STATE_ACTIVATED for a specific device until there is no more portal
>     * NM regularly does the Captive portal detection (connectivity check) to determine if the login using GNOME was already done
>     * Once the login was done and Internet connectivity is detected, NM triggers some event in nm-dispatcher (or something like that)
>   * GNOME side
>     * GNOME Shell does not do detection itself, but relies on the NM (as already done)
>     * GNOME is watching the change of "connectivity state" property in NM
>   * dnssec-trigger side
>     * Does not do any detection
>     * does not do any user interaction
>     * Only relies on events triggered by NM and acts based on the connectivity status
> 
> * Captive portal handling (login)
>   * GNOME side
>     * If Captive portal is detected, then browser window is launched
>     * The browser window ls launched with LD_PRELOAD (https://github.com/hadess/resolvconf-override) as resolv.conf override
>     * GNOME should fetch the connection-provided DNS servers using NM API (existing) and use those for LD_PRELOAD solution
>   * dnssec-trigger side
>     * does not do any user interaction
>     * Only relies on events triggered by NM and acts based on the connectivity status
> 
> * User interface / user interaction
>   * Fedora Workstation product
>     * GNOME shell
>       * informs the user about the Captive portal
>       * launches the window 
>     * dnssec-trigger
>       * the applet will be split into separate package and not installed by default (already done)
>       * if all falbacks fail, it switches automatically to "Insecure" mode (no DNSSEC validation) without user interaction
>         * automatic switch to insecure mode will be possible to turn off using configuration file for expert users
>         * a notification can be emited about switching to insecure mode (so far by default OFF)
>   * Other desktops / Spins
>     * dnssec-trigger applet
>       * should handle the UI that is usually handled by GNOME Shell (if there is not any specific Spin implementation to do that, i.e. if GNOME is not in use)
>       * Captive portal detection will be still done in NM
> 
> * under discussion:
>   * notification can be turned OFF by default, but configurable in config file for expert users - unfortunatelly this will not create pressure on admins to fix the networks
>   * alternative: display a message which will say that local network is broken and that admin should be woken up:
>     * 'Your network is seriously broken. Go and kick your network admin NOW!
>     * This broken network will stop working from Fedora 24 on because it does not support DNSSEC. (Tell this to your admin!)'
>     
> 
> [1] https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
> [2] https://www.piratepad.ca/p/default-dns-resolver-f23
> [3] https://bluejeans.com/s/8pTY/
> 
> 
> Regards,
> -- 
> Tomas Hozza
> Software Engineer - EMEA ENG Developer Experience
> 
> PGP: 1D9F3C2D
> Red Hat Inc.                 http://cz.redhat.com