VPN plug-ins and GTK3 support

[thom311 at gmail.com]

On Thu, 2025-03-20 at 12:10 +0000, David Sommerseth wrote:
> On 20/03/2025 12:41, thom311 at gmail.com wrote:
> [...snip...]
> > 
> > 1) D-Bus Daemon – Required. This is run by NetworkManager to
> > configure
> > the network. See the VPN Connection.program entry in nm-openvpn-
> > service.name.
> 
> I've spotted this one, but not dug into that aspect just yet.  From
> what
> it looks to me, in OpenVPN context, is that it is basically
> responsible
> for kicking off the /usr/sbin/openvpn binary with the proper
> arguments -
> and provide D-Bus API for NetworkManager to stop the tunnel, as well
> as
> getting credentials passing working.
> 
> Is this correct?
> 
> OpenVPN 3 Linux is doing things very different - compared to the
> "classic" OpenVPN.  With OpenVPN 3 Linux, it is now fully D-Bus
> managed.
> It has its own configuration and session management - and
> unprivileged
> users can interact with these services via D-Bus or the various
> front-end tools (like the openvpn3 command) and they are restricted
> to
> only the configuration profiles and sessions they own or have been
> granted access to.  This way it provides full privilege separation as
> well.
> 
> So this NM-openvpn3 service would basically just be a tiny broker
> app,
> handling the signals the client process/service sends and propagate
> that
> to the NM stack.  At least, that is how far my understanding has come
> so
> far.

With current openvpn, this is /usr/libexec/nm-openvpn-service.

I would say, this is also just a "(not so) tiny broker app" that spawn
openvpn binary.

Whether this D-Bus service spawns openvpn, talks to another daemon, or
implements the VPN itself, is not very important. You will need a
similar babysitter/broker app.

... unless you come up with a new, general way how the NetworkManager
daemon activates the VPN connection. For example, openvpn3 could
implement a general management D-Bus API, and NetworkManager could
learn to talk that API directly.

This seems non-trivial though. If it were, we would have created a
"better" API long ago (good luck).


> 
> 
> > 2) glib-based Plugin (/usr/lib64/NetworkManager/libnm-vpn-plugin-
> > openvpn.so) – No GTK/GUI dependency. Provides import/export
> > functionality used by nmcli, nm-connection-editor, gnome-control-
> > center, and potentially others (but not plasma-nm).
> 
> Yeah, I got very basic and hackish PoC working here.  This one is
> clear.
> 
> > 3) GTK3 Plugin (/usr/lib64/NetworkManager/libnm-vpn-plugin-openvpn-
> > editor.so) – Previously used by gnome-control-center (now GTK4).
> > Currently only used by nm-connection-editor. While it could be used
> > by
> > other GTK3 apps, I don’t think it is(??).
> > 
> > 4) GTK4 Plugin (/usr/lib64/NetworkManager/libnm-gtk4-vpn-plugin-
> > openvpn-editor.so) – GTK4 version of (3). Used by gnome-control-
> > center
> > but likely not by anything else(??).
> 
> Gotcha ... so both will be needed eventually, but for basic GNOME
> integration, GTK4 is the important one this round.  How are the
> plugins
> related to the GNOME Shell integration where you start the VPNs from
> the
> meny at the top-right corner?

The gnome-shell does the same as nm-applet.

It looks at connection profiles in NetworkManager and provides a GUI
for activating them. It special handles profiles with
connection.type=vpn. But all it does, it tell NetworkManager to
activate/decative the profile. It does not need VPN-specific knowledge
how to do that (and does not need a VPN plugin).

... except for secrets. For that, it calls to the auth helper (below).

> 
> > 5) plasma-nm – Reimplements (2) and (3)/(4) in Qt for KDE
> > integration.
> > Ideally, it would use the glib plugin (2), but I believe it
> > doesn’t(??).
> 
> That's a missing piece I was unaware of.  I'll dig into that after
> GTK3/4 is in place.

For VPN plugins, the KDE community contributed this part mostly on
their own (thanks).


> 
> > 6) Auth Dialog – An executable (any language) spawned by nm-applet,
> > gnome-shell, nmcli, and nmtui to request secrets. Likely required.
> 
> Yeah, that one looks needed.  OpenVPN 3 Linux will also support
> web-based authentication.  Can this auth-dialog trigger opening a
> URL?

In principle, the binary can do anything.

For example, for openconnect it necessarily needs to open some sort of
browser.

Optimally, the auth dialog also works without a graphical interface. 


I just realized that nmcli does not use the auth dialog. Instead it
hard-codes the supported VPN types (which is probably rather bad). For
example, openconnect is also special cased to open a browser-like tool:

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/42349205dd21adff0b78bcb16e520568f9a26374/src/nmcli/common.c#L647


In general, applications like nmcli, nmtui should be agnostic to the
VPN type. For example, by using the auth dialog.



> 
> And how is this spawning triggered?  I also see this pulls in GTK, so
> I
> presume there is a related one for plasma-nm as well?

this is what nmtui does:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/42349205dd21adff0b78bcb16e520568f9a26374/src/libnmc-base/nm-secret-agent-simple.c#L793

or nm-applet:
https://gitlab.gnome.org/GNOME/network-manager-applet/-/blob/b7687bf743e785430670e6e0127c6bdf585a43e0/src/applet-vpn-request.c#L687


> 
> [...]
> > 
> > gnome-shell is GNOME-only, whereas nm-connection-editor remains the
> > main GUI for non-GNOME, non-KDE desktops. This justifies GTK3
> > support.
> 
> Absolutely!
> 
> > Alternatively, push for the effort to port nm-connection-editor to
> > GTK4. Although, I wonder whether GTK3 support can be fully dropped,
> > because it also means to stop supporting desktop environments that
> > don't want to use GTK4 (does that exist?).
> 
> If the majority of Linux distributions ships GTK4 ... why should some
> smaller distributions be allowed to hold NetworkManager "hostage" to
> have their own use cases covered?  After all, it adds maintenance
> burden
> to NM - so if these distributions really want/need GTK3 support, then
> they could do that work themselves.   But that's just my own personal
> 2cents.

Makes sense.

Also, I guess even if a desktop environment is GTK3 at it's core, it
still can use a GTK4 application.

So the only reason might be that nobody did it (yet).



Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 512 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/networkmanager/attachments/20250320/67d4e8b8/attachment-0001.sig>