I find sysupdate’s approach preferable for a few reasons (in no particular order):
- It’s already deeply integrated into systemd
- We don’t have a package manager, so any benefit of being able to generate custom OCI images with custom package overlays and deploying them via bootc is completely lost on us. We simply can’t do that anyways, even if we use bootc. So really it’s unclear what the benefit of OCI would be for us. If we were to use bootc, we’d be using it as a basic A/B system anyways.
- It enables UKIs, secure boot, and TPM-backed encryption of data partitions. Bootc has also started offering this, but at the time the decision was made this was simply not the case. Anyways, bootc’s approach also has some security gaps that sysupdate doesn’t: bootc requires the OS to mount an untrusted filesystem image before it can continue loading the verified OS contents off of that image. Linux’s filesystem developers have been very clear: filesystem drivers are not designed to be robust against a malicious filesystem image. So an attacker could theoretically circumvent bootc’s code signing by maliciously crafting the filesystem itself to attack the kernel and disable the checksumming. sysupdate doesn’t need to mount any untrusted filesystems to boot; everything is always trusted, and so no such attack is even theoretically possible.
- bootc is designed to share the filesystem with your actual user data. This has reprocussions:
- If you want to encrypt your data, you have to encrypt the OS too. If the OS is truly immutable, like GNOME OS is, the only thing you get by encrypting the OS is worse performance. Encrypting the OS is also bootc’s suggested workaround for the above mentioned secure-boot gap
- If you have too many files in your home directory and fill up enough of the disk, there won’t be enough space left over for bootc to install any more system updates. This is an issue that plagued ostree too; I’ve definitely run into situations where I need to go delete a bunch of stuff to free up space to download a system update. sysupdate pre-allocates all the disk space that it would ever need, and it always downloads updates directly into their final destination, so it never actually needs any additional disk space to apply an update. So updates can never fail due to lack of disk space with sysupdate, which is very very important IMO.
- It makes it harder to implement a factory-reset feature, and even when implemented it’ll be less secure. With sysupdate, you can do a secure wipe of your system just by by discarding the encryption keys and marking the root partition as deleted. At that point, there’s no chance of recovering any data. On the next boot, the OS detects that it doesn’t have a root partition, so fresh encryption keys are generated and a new root partition is created. With bootc, since the filesystem is shared, the best you can do is just delete the data folders within the running filesystem. This just marks the space as available, but doesn’t actually delete any data. This means that the data is still there and is easily recoverable by various tools. The only way to securely wipe a bootc system is to erase the encryption keys, like you would on sysupdate. But this erases the OS too, which means that you’ll need to then re-install the OS from scratch from external media.
- sysupdate is generally the less complicated solution, and our needs aren’t that complicated for GNOME OS. It seemed like the better fit for us.
To be clear, I don’t have anything against bootc. For hybrid-immutable distributions like Fedora Silverblue, it’s probably better suited, and the limitations of sysupdate might get in the way in those usecases. Also, the OCI tooling combined with a package manager does make deployment of custom images super convenient for an enthusiast Linux user, and generally sysupdate images are harder to generate. Our usecase just happens to be better suited by sysupdate.