It is not hard to deal with, and you can always just maintain a container image based on SecureBlue and layer additional X11 packages. If a template were to be made, Qubes would need to maintain their own images and bundle in Qubes specific tools anyways.
Also, while this does not matter in a Qubes environment, it matters significantly if you are going to run these guests with KVM or something else. Using X11 like Whonix essentially makes the isolation between apps useless.
have used kicksecure myself and have never had a problem with it, and I have never come across any group that claim whonix is insecure other than the GrapheneOS crowd.
Like others have said, Debian is a very bad base to be building on. Packages go outdated and miss vulnerability fixes, and the maintainers will happily bastardize the packages for no apparent reason other than their own personal preferences. See this for example: Debian No-Feature KeePassXC Package · Issue #10725 · keepassxreboot/keepassxc · GitHub
If you ever try to do in-depth configuration of Debian, you will notice that their software behaves differently from upstream documentations, and a lot of times they invent really weird stuff instead of using standard tooling and just end up producing a far worse product. Sometimes, it is even worse than the upstream that they are basing their stuff on. An example would be how they handle initramfs generation.
The additional hardening that KickSecure provides cannot make up for the downsides of the Debian base, and it doesn’t have nearly as much hardening as SecureBlue to begin with.
Comparison of secureblue with Kicksecure and Development Notes
The page is highly misleading and misses a lot of hardening that SecureBlue actually does.
@ryrona already covered some of this, but I will expand on this a little more:
Debian offers reproducible builds to verify trust which Fedora does not
Reproducible builds mean nothing if the thing you can reliably reproduce is garbage (outdated packages with terrible downstream patching that doesn’t make any sense).
Others prefer the perceived increased trust that Debian offers.
IMHO Debian decreases trust significantly because you cannot even trust that packages will behave the same way upstream documentation says.
Kicksecure’s Wiki also says a lot of ridiculous stuff, including:
At this point, Kicksecure (and Whonix) runs primarily inside VMs. GNOME and KDE are unsuitable for Kicksecure.
This makes absolutely 0 sense. GNOME runs just fine inside of VMs and it is what I personally use outside of the Qubes environment. That cannot possibly be a justification to stick to XFCE.
but kicksecure says that hardened_malloc hardly works with anything, such as many programs (firefox and probably many others) not working.
Kicksecure’s claim here is objectively false, considering that I use hardened_malloc on almost all of my stuff, including:
- Fedora workstations
- Virtual Machines
- Fedora and RHEL servers
- Flatpak containers
- OCI containers (yes, I port upstream containers to Alpine Linux and include hardened_malloc in there)
There are incompatibilities, but they are very few and far between.
- Architecture support: Limited. (HM supports AMD64 architecture only, which makes Kicksecure progress towards multiple architecture support such as ARM64 and PPC harder.)
I also have 0 idea what they are trying to say here. hardened_malloc works fine on both my aarch64 Linux systems and aarch64 containers. If anything, they seem to have forgotten that hardened_malloc is written for GOS, which runs on ARM devices.
Potential future deprecation by upstream
Not happening anytime soon, especially with projects like SecureBlue using it.
Kicksecure Wiki spreads a fair bit of terrible and misleading information regarding other non-competing projects/products too, including: