I don’t think they have any intention of doing so. It means they can’t innovate as quickly and need to spend resources registering changes. Fedora has more resources and enterprise users. My favourite distro doesn’t have secure boot and I run so many different ones I don’t even enable it ussually. You should if you can though.
For more context Linux mint is not recommended by Privacy Guides because it does not meet the minimum criteria, namely providing a stable Wayland desktop environment.
References:
P.S.
In the last half decade or so the few Linux distributions that I have encountered that didn’t support secure boot were Qubes OS, and Arch Linux derivatives.
Actually for those use cases, while there is a learning curve, I don’t think you’d really run into many “headaches”. Once you’ve figured out your way around the system it should “just work” for those purposes.
Of course it’s totally fine and understandable if OP doesn’t want to deal with that learning curve though. I’m not necessarily saying they should use Qubes.
Debian only gets a new stable release every 2 years.
3 years
Mint relies on AppArmor while Fedora uses SELinux, which is a hardened kernel.
SELinux is not a “hardened kernel”. AppArmor and SELinux are both Linux Security Modules which allow implementing forms of Mandatory Access Control on Linux, with differences in design philosophy between the two. SELinux is generally viewed as more powerful but also much harder to configure, while AppArmor is much easier to set up but is viewed as being less powerful. As an example, SELinux applies restrictions based on labels which must be preapplied to filesystem objects, while AppArmor applies based on VFS path as defined entirely within the profiles that configure the restrictions.
Qubes OS does not yet support secure boot: Source
It’s better to read their documentation on this as that isn’t the whole story:
UEFI Secure Boot is not supported out of the box as UEFI support in Xen is very basic. Arguably secure boot reliance on UEFI integrity is not the best design. The relevant binaries (shim.efi, xen.efi, kernel / initramfs) are not signed by the Qubes Team and secure boot has not been tested. Intel TXT (used in Anti Evil Maid) at least tries to avoid or limit trust in BIOS. See the Heads project [1] [2] for a better-designed non-UEFI-based secure boot scheme with very good support for Qubes.