This bug now applies only to SSH, OpenVPN can load editor

Proposed as a Blocker for 36-final by Fedora user sasha using the blocker tracking app because:

 This bug can make access to the Internet or certain network services impossible or insecure for some users.

There's a PR open for the SSH plugin upstream[0].

It can't just be pulled in as a simple patch because it generates a GTK4 compatible ui file during generation of the tarball instead of simply adding a ui file to the source tree and modifying the Makefile.

Option 1 would be to pester upstream to cut a new release with the PR incorporated. Option 2 would be to run `gtk4-builder-tool simplify --3to4` like the Makefile does and include the result as a patch.

Either way, component should be changed to NetworkManager-ssh.

[0] - https://github.com/danfruehauf/NetworkManager-ssh/pull/110

Bug confirmed in latest F36.

Discussed during the 2022-04-11 blocker review meeting: [1]

The decision to classify this bug as an RejectedBlocker and AcceptedFreezeException was made:

"We believe that ssh-based VPN is not widely used enough to warrant a blocker status, however we do see this as bad and grant it FE status."

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2022-04-11/f36-blocker-review.2022-04-11-16.00.log.txt

NetworkManager-strongswan plugin has the same issue in F36, I filed https://bugzilla.redhat.com/show_bug.cgi?id=2081321

This bug is for adding or editing a SSH VPN connection with the gtk4 based gnome-control-center, the gtk3 based nm-connection-editor (from the nm-connection-editor RPM) still works and can be used as a workaround to add or edit a SSH VPN connection.

A pre-built gtk4 ui file doesn't need to be bundled with the tarball, it isn't with NetworkManager-l2tp. For the other VPN clients that were released earlier, they had to bundle a pre-built gtk4 ui file as a workaround for 'gtk4-builder-tool simplify --3to4' needing a display in the build environment to work. The 'gtk4-builder-tool' no longer needs a display for the 'simplify' subcommand as described in the following merge request (which corresponds to gtk4-builder >= 4.6.2) :
   https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4415

I think that github PR could directly be incorporated as a patch, but the following two lines would need to be run before the %configure line :

autoreconf -fi
intltoolize


So that the autoconf related files that are generated and normally added to the source tarball are regenerated after the patch is applied.

Sorry forgot to mention, the PR patch would be :
https://patch-diff.githubusercontent.com/raw/danfruehauf/NetworkManager-ssh/pull/110.patch

"For the other VPN clients that were released earlier, they had to bundle a pre-built gtk4 ui file as a workaround for 'gtk4-builder-tool simplify --3to4' needing a display in the build environment to work. The 'gtk4-builder-tool' no longer needs a display for the 'simplify' subcommand"

This is true, but GTK devs still say that this is not how you're supposed to do things. They do not recommend generating a gtk4 file on-the-fly from one intended for gtk3. The tool is meant to be used one time and the output reviewed and tweaked by a human, then maintained.

> This is true, but GTK devs still say that this is not how you're supposed to
> do things. They do not recommend generating a gtk4 file on-the-fly from one
> intended for gtk3. The tool is meant to be used one time and the output
> reviewed and tweaked by a human, then maintained.

Yet the GTK devs relented and allowed the tool to not need a display using a different approach which they committed and is in gtk4-builder >= 4.6.2.

What the GTK dev says makes sense for a GTK4 standalone application, but for VPN editor plugins that are used by both gtk3 and gtk4 applications it really doesn't make much sense to manually maintain separate gtk3 and gtk4 ui files. This situation with 2 separate ui files will have to remain until all the applications using the NM plugins have been ported to gtk4.

All the NetworkManager VPN (gtk3) ui files have been manually modified to replace or remove items not compatible with gtk4 and gtk4-builder-tool.

I opened https://bugzilla.redhat.com/show_bug.cgi?id=2086928 and I assume my problem is relative to this one.

After upgrade from 35 to 36 I can open VPN connection editor but with my old user who worked fine in 35 I get garbage in displayed panel.

If I create a new user, VPN connection editor works fine and displayed panel is correct.

I've created Fedora 36 NetworkManager-ssh 1.2.12 RPMs built with the NetworkManager-ssh GTK4 pull request and put them up on this COPR repository:

    https://copr.fedorainfracloud.org/coprs/dkosovic/NetworkManager-ssh-gtk4/

Please test them by editing (or adding) SSH VPN connections with gtk4 based gnome-control-center and gtk3 based nm-connection-editor.

You can view what I changed in NetworkManager-ssh.spec file by looking at : 
    https://github.com/dkosovic/NetworkManager-ssh-gtk4/commit/26f634dce636380e2c00a06f4426d57bf9d7d38c

Regarding the NetworkManager-ssh GTK4 pull request, https://github.com/danfruehauf/NetworkManager-ssh/pull/110, the actual patch I used unmodified was:

    https://github.com/danfruehauf/NetworkManager-ssh/pull/110.diff

instead of using the following patch which is a concatenation of commit patches :

    https://github.com/danfruehauf/NetworkManager-ssh/pull/110.patch

as there was an issue applying the latter patch due to one of the files being renamed and subsequently modified in multiple commits.



If you want to avoid adding the above COPR repository, the NetworkManager-ssh-1.2.12-4.fc36.x86_64.rpm and NetworkManager-ssh-gnome-1.2.12-4.fc36.x86_64.rpm files can be downloaded directly from :

https://download.copr.fedorainfracloud.org/results/dkosovic/NetworkManager-ssh-gtk4/fedora-36-x86_64/04441640-NetworkManager-ssh/

and then installed with

   sudo rpm -Uvh NetworkManager-ssh-1.2.12-4.fc36.x86_64.rpm NetworkManager-ssh-gnome-1.2.12-4.fc36.x86_64.rpm

(In reply to Didier G from comment #12)
> I opened https://bugzilla.redhat.com/show_bug.cgi?id=2086928 and I assume my
> problem is relative to this one.

I don't think the issues are related, this issue is about not having a gtk4 ssh vpn plugin, that issues is about the gtk4 openvpn vpn plugin causing an unresponsive spinning wheel when a connection from an older version is loaded.

There was one issue I discovered with the NetworkManager-ssh RPM package I created, the main package still had a stray gtk3 requires dependency which is not ideal for KDE plasma-nm or command-line nmcli users where pulling down gtk3 and its dependencies is not required. The auxiliary NetworkManager-ssh-gnome RPM package is the one that will pull down gtk3/gtk4 and GNOME dependencies.

My latest NetworkManager-ssh RPM spec file is :
https://raw.githubusercontent.com/dkosovic/NetworkManager-ssh-gtk4/main/NetworkManager-ssh.spec

and the corresponding NetworkManager-ssh-1.2.12-gtk4.patch file is still :
https://github.com/danfruehauf/NetworkManager-ssh/pull/110.diff

I didn't bother creating new RPM binary files on COPR as the functionality hasn't changed for the gtk4 based gnome-control-center.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle.
Changing version to 37.

This is also the case for the fortisslvpn plugin
can we get a quick an simple workaround?

(In reply to comment #17)
> This is also the case for the fortisslvpn plugin
> can we get a quick an simple workaround?

Extract from the NetworkManager-fortisslvpn-1.4.0 NEWS file :

https://gitlab.gnome.org/GNOME/NetworkManager-fortisslvpn/-/blob/1.4.0/NEWS

    Notable changes include:

    * Gtk4 version of the editor plugin is now available (for use with
      Control Center of GNOME 42 or later).

This issue is about the NetworkManager-ssh 1.2.12 RPM not including a Gtk4 version of the editor plugin.

I believe the Fedora 36 NetworkManager-fortisslvpn 1.4.0 RPM is built with Gtk4 support :
https://src.fedoraproject.org/rpms/NetworkManager-fortisslvpn/blob/f36/f/NetworkManager-fortisslvpn.spec

So I suspect you have a different issue to the one here.

The problem is also not solved with 1.2.12-5.fc38...

Can somebody please file an upstream ticket at https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues and link it here?

(In reply to Kamil Páral from comment #20)
> Can somebody please file an upstream ticket at
> https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues and link it
> here?

Actually, I take it back, this seems to be a problem in NetworkManager-ssh and there's already a PR ready, marking as such:
https://github.com/danfruehauf/NetworkManager-ssh/pull/110

Hi all, I'm a bit late on that train, but please let me know if there's anything I can do with regards to that. Looks like Lubomir has taken care of everything already :)

Lubomir's GTK4 PR hasn't been merged upstream.

My latest NetworkManager-ssh RPM spec file which applies that PR as a patch and has a number of other fixes is located here:
https://github.com/dkosovic/NetworkManager-ssh-gtk4

and the corresponding NetworkManager-ssh-1.2.12-gtk4.patch file for that PR is :
https://github.com/danfruehauf/NetworkManager-ssh/pull/110.diff

I've built the RPMs for the last 3 Fedora releases from the above RPM SPEC and patch files here:
https://copr.fedorainfracloud.org/coprs/dkosovic/NetworkManager-ssh-gtk4/


The RPM spec file contains a number of fixes which probably should be applied upstream, along with the PR, there is also :

# Use /usr/share/metainfo for AppData files, should fix upstream
sed -i 's!(datadir)/appdata!(datadir)/metainfo!' Makefile.am

# Use /usr/share/dbus-1/system.d/ for D-Bus policy file, should fix upstream
sed -i 's!(sysconfdir)/dbus-1/system.d!(datadir)/dbus-1/system.d!' Makefile.am

Ideally there should be a new upstream release, but if you want to use my new RPM spec file and the NetworkManager-ssh-1.2.12-gtk4.patch file that would do for the time being.

Confirmed still present in F38

This message is a reminder that Fedora Linux 37 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '37'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 37 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.