It really pains me that not a single Linux distro even wants to talk about the following issue: if you want to use out of tree kernel modules you either have to disable secure UEFI boot or mess with your own MAK keys which is extremely complicated and near impossible for absolute most users out there.

This is not even close to true. Fedora Workstation has had discussions about this for years now, and that working group is trying to figure out a solution. See fedora-workstation#155.

I agree that the current situation is horrible and that the folks who designed this did not consider how much of a problem it was for regular users to set this up. It's being worked on.

Is licensing above security?

The choice being legally distributable and non-distributable is a very easy one: yes, we need to be distributable.

Can we talk about that in a civil manner without screaming they are not GPL2 compliant thus users ... must suffer?

This is a very antagonistic way to start the discussion. For what it's worth, on your list, only VMware Workstation and the NVIDIA driver are not GPLv2 compatible. We provide an easy path to enable the latter, but we're unlikely to do anything about the former.

VirtualBox is merely "tainted crap" (upstream's label for this) for being unreliable code. The guest additions were upstreamed by @jwrdegoede, while the host modules remain out of tree as VirtualBox did not want to commit to a stable interface to allow them to be upstreamed. You're more likely to convince VirtualBox to switch from their own accelerator modules to using the KVM one than to get us to do anything about VirtualBox, especially as we ship libvirt backed by qemu+kvm by default already.

As for the Realtek drivers, I believe there's already an effort going on for upstreaming them. Perhaps @jwrdegoede would know?

Realtek themselves are actually working on getting support for their latest wifi chipsets added to the mainline kernel and recently this has landed. So wrt realtek wifi support we should be in pretty good shape.

This is not even close to true. Fedora Workstation has had discussions about this for years now, and that working group is trying to figure out a solution. See fedora-workstation#155.

Thanks, didn't know the issue already exists.

I'm reopening this issue because the already existing issue discusses proprietary NVIDIA drivers/modules with a questionable licensing and packaging situation.

On the other hand VirtualBox, VMWare Workstation and multiple not yet mainlined completely open source drivers are still the issue.

The solution for NVIDIA will likely be extensible to VirtualBox and VMware Workstation. VirtualBox, being open source and available from RPM Fusion, will take advantage of it. VMware Workstation will require VMware's cooperation (though I don't think they ship RPMs for their stuff?).

I would advise you file a ticket on the Fedora Workstation tracker asking about the Realtek drivers, as that group is the one working on upstreaming hardware enablement.

OK, maybe it 10 years. I get it.

OK, maybe it 10 years. I get it.

Why do you think it'd be ten years? We're actively working on these things...

NVIDIA has recently stated that:

https://forums.developer.nvidia.com/t/unix-graphics-feature-deprecation-schedule/60588

Open Linux Kernel Modules Installed by Default

Starting in the release 560 series, it will be recommended to use the open flavor of NVIDIA Linux Kernel Modules 265 wherever possible (Turing or later GPUs, or Ada or later when using GPU virtualization).

If installing from the .run file, installation will detect what GPUs are present and default to installing the open kernel modules if all NVIDIA GPUs in the system can be driven by the open kernel modules. Distribution-specific repackaging of the NVIDIA driver may require additional steps, specific to that packaging, to choose the open flavor.

In the release 560 series, it will still be possible to configure the .run file to install the proprietary flavor of kernel modules, with the --kernel-module-type=proprietary command line option. However, in the future, some GPUs may only be supported with the open flavor.

Maybe Fedora could reconsider building and signing at least NVIDIA drivers, no?

I get it VirtualBox users are forever screwed but proper HW support could be ... I don't know ... an essential feature, no?

Well, for these same GPUs, Nouveau and NVK will also work, since both the "open" drivers and Nouveau use the same firmware code to initialize and configure the GPU. And graphics performance should be quite comparable, since reclocking is now supported.

nouveau is far from perfect and it has a lot of very rough edges. It's only if your NVIDIA GPU is at least 10 years old that it works more or less OK, barring glaring performance issues.

Meanwhile your users continue to suffer: https://www.reddit.com/r/Fedora/comments/1d43567/i_installed_oracle_virtual_box_on_fedora_linux/

It must take a lot of courage to make users disable Secure Boot and continue to prove you care about security.

nouveau is far from perfect and it has a lot of very rough edges. It's only if your NVIDIA GPU is at least 10 years old that it works more or less OK, barring glaring performance issues.

The nouveau and nvk drivers are open-source and ready to accept your patches to improve things.

Meanwhile your users continue to suffer: https://www.reddit.com/r/Fedora/comments/1d43567/i_installed_oracle_virtual_box_on_fedora_linux/

I think your definition of "suffer" and mine are wildly different.

It must take a lot of courage to make users disable Secure Boot and continue to prove you care about security.

Snarky comments are not historically a great way to advocate for changes.

We're not telling users to disable Secure Boot; even Oracle's error message here is quite clear: the user might need to manually sign the module. Secure Boot is doing it's job: it's refusing to load kernel modules from unknown third-party sources. That's literally why it exists.

insofar as Secure Boot provides security (there's some valid questions there and it's a whole other topic), it's important to note that signing something in the Secure Boot chain is essentially an assertion that we have vetted a piece of software and are willing to guarantee that it's safe for you to load into the kernel. We cannot do that with out-of-tree kernel modules because we haven't built them. Our signing process is part of our build process. That's why we provide documentation on how to add new signing keys if the user is willing to take on the responsibility of vetting third-party kernel modules. We won't blindly include a signing key for a third-party because we (Fedora) are not willing or able to assume liability for someone else's code.

The reason that VirtualBox and nVidia have this problem is that they don't do their work upstream with the Linux kernel. If they did so, we'd be able to just sign their modules along with all the others we build.

If we can't build the code, we cannot reasonably assert that the kernel module is safe to load into the system. Either the user needs to explicitly load some additional keys to their trust chain manually or they need to disable the Secure Boot system and accept the risks of doing so.