While we default to our own PureOS on our hardware, we have also supported the high-security QubesOS on Purism hardware ever since the Librem 13 v1 became the first hardware officially supported by the Qubes project. Since then we have continued to treat Qubes as a first-class citizen and ensured that it works well on new iterations of our hardware, up to and including our current Librem Mini and Librem 14 which we feel is the best laptop for running Qubes. We are pleased to announce this support now extends to pre-installing Qubes on the Librem Mini and Librem 14, for any customer who selects it as their OS of choice.
Did you consider sending an official report to the Qubes hardware compatibility list? This will show that you indeed tested the devices and confirm that they work well with Qubes OS. By the way, Librem 14 got into the “just works” hardware list for Qubes.
I’ve been reluctant to post to the hardware compatibility list ever since my last attempt a few years back, which turned into a thread full of anti-Purism trolling without any moderation from that team (and I don’t believe despite all of that, that my post actually made it into the hardware compatibility list itself!) It just doesn’t seem worth it and I don’t want to subject anyone else on the team to that, but if someone unaffiliated with Purism wants to do it, they are more than welcome.
It’s sad to hear that. I would still try again to do that if I were you, because that would show the official vendor support of Qubes OS, which is an extremely rare thing and could be mentioned in the “just works” list linked above. Both (Qubes and Purism) communities are much larger now and there will be a lot of observers, including the moderation. (By the way, I am almost a moderator there, too). See the thread with the HCL reports for Librem 14v1 maintained by me.
FWIW, We’ll likely never get certified as long as the “must ship the same BIOS for 1 year” requirement exists. I’m not sure what’s driving that requirement, but it’s nonsensical given the way modern devices work.
I sort of agree with this sentiment, however one thing that is different about how we approach security is that while we’d like to think that customers can trust us, we also try to design things so that customers don’t have to anchor their trust in us to be secure.
This is one reason why we try to use free software everywhere we can, so that customers have the option to audit (or pay someone else to audit) security-critical code, the code can ideally be reproducibly built (which we continue to work to increase the code coverage for that), and customers in general can build and install their own software from source on the hardware and overwrite whatever we do.
This is why we went with PureBoot instead of a traditional SecureBoot process that would require you to trust Purism keys that would sign binaries. The initial phase of PureBoot (and the addition of the anti-interdiction service for people who want even stronger assurances) is simply so the customer can confirm “this laptop is in the same state as it was when it left Purism’s custody.”
After that point, however, there is a risk in the fact that we pre-installed the OS, so we technically could have made a copy of the LUKS master key, even though we don’t, and could have theoretically installed some kind of software or firmware backdoor, even though we don’t do that either. Also for PureBoot, we initially set up a GPG key that is created on the Librem Key and in theory we could export that too (even though we don’t). This is why we advise people to change the PIN and GPG keys for PureBoot either manually or through an OEM Factory Reset, after they verify the initial state of the hardware and firmware.
All of this is perfectly reasonable and safe for the average customer of ours who faces average threats. Convenience does matter, and so we try to balance giving people good security, without making it incredibly inconvenient just to satisfy edge-case, incredibly-unlikely-to-affect-them threats.
For customers who face stronger-than-average threats, they are probably used to some extra level of inconvenience, and would need to take their particular threats into account. Those folks should be sophisticated enough to know whether they need to take additional steps such as wiping and reinstalling the OS or the boot firmware using images they personally verified.
Could the original intent have been about proprietary BIOSes? You know, hard (impossible) to actually verify.
Maybe they’d consider liftting that requirement for CoreBoot?
My librem mini came password protected with Qubes OS preinstalled. Is this normal and if so how to resolve this? Its asking for a passphrase on boot up.
This is an artifact of the Qubes OEM installer. We have to set some kind of disk unlock passphrase, so we set an empty one temporarily (like with PureOS) so you can get to the wizard and set a custom one. Just hit Enter and it should proceed.