Why not propose to have it added to @standard?

Workstation does not include @standard.

the UX is currently not complete and still require operations via the wg command line tool from this package.

In that case, the gnome-control-center RPM should Recommends: wireguard-tools. But are you sure it's really required by this gnome-control-center merge request?

wireguard-tools is not really a desirable dependency because NetworkManager is the ideal way to edit your Wireguard connections in Workstation.

Edited to fix a duplicated link that should have pointed to https://blogs.gnome.org/thaller/2019/03/15/wireguard-in-networkmanager/

But are you sure it's really required by this gnome-control-center merge request?

I'm not sure that gnome-control-center will require it as it's not going to use it to generate keys. It will only let users edit connections or create new ones.

NetworkManager is the ideal way to edit your Wireguard connections in Workstation.

I agree, it should be, but the support is currently incomplete.

Maybe I should rephrase this to mention that this a temporary until full support is implemented/merged in NetworkManager / GNOME UI.

Why not propose to have it added to @standard?

Sounds reasonable too. How should I do that?

Workstation does not include @standard.

This is something we should fix.

Maybe I should rephrase this to mention that this a temporary until full support is implemented/merged in NetworkManager / GNOME UI.

The upstream merge request looks ready to be merged. I've just poked it to make sure it's on track. Would be quite disappointing if it slips past GNOME 44.

I don't see any reason to add command line tools as a workaround for missing UI, because anybody who knows that the tool exists will also know how to install it.

Why not propose to have it added to @standard?

Is it important enough to go there, considering that most Wireguard users will never need it? Too much stuff in @standard is why we stopped using it.

This is something we should fix.

Probably yes, but not in this ticket. ;)

I don't see any reason to add command line tools as a workaround for missing UI, because anybody who knows that the tool exists will also know how to install it.

It's easy to add on Workstation but less easy on Silverblue.

If the answer is "this is useful but easy to add after the fact" for Workstation then we can consider adding it just for Silverblue. See https://github.com/fedora-silverblue/issue-tracker/issues/390.

If the answer is "we should not add this at all as we want users to use something else / not use wireguard" then I'd say we won't include it in Silverblue.

I don't think wireguard-tools should be needed on Silverblue. Use the built-in NetworkManager functionality instead.

This was the wrong decision.

The creator of WireGuard says that wireguard-tools is required. Does @catanzaro know better?

This was the wrong decision.

The creator of WireGuard says that wireguard-tools is required. Does @catanzaro know better?

I can understand disagreeing with a previous decision but personal attacks are never OK. Please stop doing that.

It was not a personal attack; anyone claiming to know better than the creator and steward is probably making the wrong decision.

NetworkManager does not support all WG functionality. Brokenness exists. The creator says the tools are a hard requirement. Either we should ship the tools as well or rip out the half-baked implementation and let users who need WireGuard (quite a few of them, by the sounds of it) install all of WG themselves.

Fedora Workstation is supposed to be batteries-included. If we wanted to install everything from scratch, we'd be using Arch (btw).

It was not a personal attack; anyone claiming to know better than the creator and steward is probably making the wrong decision.

This is by definition a personal attack.

NetworkManager does not support all WG functionality. Brokenness exists.

File bug reports with NetworkManager. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues

The creator says the tools are a hard requirement.

This is obviously false because things like Tailscale that use WireGuard don't use it. The tools are not a hard requirement, it depends on how you connect and configure WireGuard. NetworkManager is its own client implementation of WireGuard, it even supports importing wg-quick configuration into its own settings storage.

Either we should ship the tools as well or rip out the half-baked implementation and let users who need WireGuard (quite a few of them, by the sounds of it) install all of WG themselves.

Or the preferred client implementation (NetworkManager) gets better. That's also an option.

It's not really a "batteries included" distro if the buttons on the device do not work. I've no doubt that wireguard-tools is a good way to get a Wireguard connection without using NetworkManager, but Fedora Workstation users expect GUI integration in both gnome-shell and gnome-control-center, and are surely much better served by using NetworkManager. Feel free to use wireguard-tools yourself, but if so you're bypassing all the desktop integration that users expect.

I've been using Wireguard connections for several years now and have myself only encountered one bug (this one). If you've found other deficiencies, then I suggest creating issue reports against NetworkManager.

If the client you prefer doesn't ship the missing functionality today, why not include the one small package known to correctly provide it, at least until it comes up to feature parity?

Why reinvent the wheel?

FWIW, the following WG config is unusable on Fedora Workstation as shipped:

[Interface]
PrivateKey = [redacted]
Address = 10.64.167.199/32,fc00:bbbb:bbbb:bb01::1:a7c6/128
DNS = 10.64.0.1
PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL ! -d 10.0.0.0/8 -j REJECT && ip6tables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL ! -d 10.0.0.0/8 -j REJECT && ip6tables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
[Peer]
PublicKey = [redacted]
AllowedIPs = 0.0.0.0/0,::0/0
Endpoint = [redacted]

It's not really a "batteries included" distro if the buttons on the device do not work.

I could not be more in agreement. I'm here trying to get some missing functionality tied to one of those buttons. Thank you.

I would create a bug report. Reconsidering OS design decisions due to a single bug is not very likely.

I would create a bug report.

and

Reconsidering OS design decisions due to a single bug is not very likely.

seem effectively mutually exclusive to me. Plus, is this not the relevant bug?

No, this isn't the place to raise bug reports. Please use the Red Hat Bugzilla for that.

For full details, check this link: https://docs.fedoraproject.org/en-US/quick-docs/bugzilla-file-a-bug/

Using a downstream issue tracker for an upstream problem is likely to end in disappointment. This is an upstream bug, so it needs to be reported to upstream. Here is NetworkManager's issue tracker.

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/workstation/tickets/issues/353

Please continue any further discussion there.