There were a couple times however I began to seriously waver from ever wanting to try to install IncusOS on bare metal.
21:37 into the video, in the BIOS, in the UEFI Secure Boot, Custom Mode Key management was shown. Yikes, what a scary looking bunch of steps for enrolling Key Exchange Key, and Authorized Signatures. When importing these files from a USB stick (“enrolling the keys by hand”):
Look at those pathnames to navigate to the files on the USB stick (highlighted in black above)! Brutal!!
Another big turnoff was the use of Yaml (at 27:45), (where it was added “roles: instances”). Debian’s systemd doesn’t use yaml in its config files, but rather a toml-like configuration syntax. I would have strongly preferred that IncusOS followed suit and made it also toml-like. Not yaml.
We sadly don’t really have any control on how BIOS manufacturers decide to implement their Secure Boot menu
Some do look better than others. Modern DELL servers come to mind as far as those having just about every last bit of the Secure Boot standard supported and a UI that mostly makes sense to manage it.
IncusOS is configured through a REST API, so all the configuration is technically JSON.
It’s the CLI that then converts the JSON to YAML to make it easier to edit.
YAML is a superset of JSON, so anything that can be exposed over the JSON API can also be shown to the user as YAML and can then be converted back to JSON to send over the API.
In theory someone could contribute a flag to the show and edit commands to use TOML but that would require a way to automatically convert any arbitrary JSON to TOML and then convert the modified TOML back to JSON. I’m not familiar enough with TOML to know if that’s something that can be done.
Thanks for explaining how JSON converts to YAML and back. didn’t know!
Rant: To my mind, UEFI is pretty much just a “complexity roadblock” to the Open Source community. Does it encumber Microsoft customers? No it doesn’t, because Microsoft’s KEK and Authorized signatures are already enrolled. It’s just the Open Source types who need to very carefully navigate that dog’s breakfast of a user interface (which is different from vendor to vendor, as you noted, adding to the complexity).
When one navigates onto the USB stick to find the files - hey, there’s trust in the USB stick to get the files! So really what’s all the fuss about having UEFI in the first place, which is all about not trusting USB boot media? Do you see how “the shoe goes on the other foot”, as it were? First it doesn’t trust that USB stick (for booting), then all of a sudden it does trust that USB stick (when it’s time to enroll the keys).
To my mind, it’s just highly-complicated busy-work (for the value one actually gets back), which will probably frighten off no small number of your potential users.
TOML can’t directly map to arbitrary JSON values, only to JSON objects, but in our use case, I’m not seeing anything that wouldn’t work. Still, I consider anything touching arrays of tables in TOML as something I want to avoid, as it feels pretty unnatural and prone to heavy brain knots…
UEFI and Secure Boot aren’t that complex, but I think the education around them is very poor. You make a point with Microsoft’s KEK, but the reality is that when UEFI was deployed, Microsoft was dominating desktop installations, and contracts with hardware vendors and the absence of 3rd-party CAs led to most chips only shipping Microsoft’s KEK.
When one navigates their USB drive from the UEFI menu, this is a manual action, done while the system is in setup (or config, or custom, etc.) mode, not something your OS really can manage.
Secure Boot really does bring in a lot of security benefits. Sure, making drivers work with it requires a bit more work (but hey, that’s why we have MOKs in most distros – not in IncusOS though), but that’s precisely to prevent someone messing with your system in ways that could even survive OS reinstall.
Thanks for the feedback, everyone. The additional context is appreciated.
I did an install of Proxmox, just to get a sense of the convenience in their install process. It was a UEFI install (from USB stick), but I didn’t have to do any manual Key management in the BIOS (just as would be the case with installing stock Linux Mint, etc).
Two other convenience-related differences:
standard password login to the web UI was permitted by Proxmox (over self-signed SSL, to avoid cleartext password input). No hand-installing a cert into the browser first, which the demo video (in the OP) mentioned the need to do, but then refrained from showing how to do that. I’ve done this in the past, and it’s actually a rather un-intuitive and annoying process (in Firefox).
When I created a new LXC container in Proxmox, the default network type was bridged (which is what I wanted); no need to hand-edit any YAML to add “roles: instances”.
I can appreciate that IncusOS is trying to stand out for being ultra-secure, but don’t be surprised when that’s really off-putting to quite a few potential users, who have been spoiled over and over, into wanting quick and easy onboarding to anything they start using.
Note: one thing I really didn’t like about Proxmox was all the nagging about getting a “Subscription” - through many ominous error message dialogues. They sort of lay a guilt trip on the end user for being a normal sort of user who’s there for the free, Open Source experience they were led into believing they could have, guilt free.
Yeah, the threat model looks a bit different, but I’d say the main difference is a technical one: Incus doesn’t really do user management. It either relies on external services for authentication and authorization, or on client certificates, which are actually emitted by an external CA in corporate environments. So no user/password pairs because Incus doesn’t touch that (reducing the attack surface), and no PAM authentication because when working on large clusters, Incus cannot reasonably check that your user exists and has the same rights everywhere (this is the same argument we have when people ask for configuration keys that rely on specific paths on the host).
Setting up mTLS can be a bit frustrating and the tooling isn’t perfect across all OSes, and installing an IAM tool isn’t the easiest, but that’s the unfortunate price to pay as Incus doesn’t want to handle it itself.
I’d say that it’s one Ansible playbook away from not displaying the infamous message, but yeah, different philosophy here
Worth noting that we’re looking at providing a basic public OIDC provider as well as have adding support for automatically deploying one locally during installation:
