Hacker News new | past | comments | ask | show | jobs | submit login

The update system is image-based; when an update is downloaded, it's written out to an alternate set of partitions, and then it can flip over to those partitions with a reboot. That makes it easy to roll back with the same kind of single flip, too.

It's different than filesystem-level rollbacks because it's all-or-nothing, so you don't have to worry about update failures after a few packages, and because all of the components in a given image are guaranteed to be tested together, whereas with package-based systems, your combination of packages may have never been used together by anyone else. In addition, for builders, it's easier to sign, distribute, and verify a single image.




How does this compare to something like nix or Fedora Silverblue?


Nix has upside that you just need to flip a symlink to do the same . Downside is that you don't have thinks like dm-verity that can prove that your update wasn't tampered with.

In nix the nix store is remounted over itself read-only, but nothing stops someone from ripping out the disk and flipping bits. This is not possible with these kind of 2-partition schemes if you have dm-verity set up


Isn't Nix a Merkle-Tree system of hashes? Doesn't that allow you to easily verify everything that you're running?


This is possible in nix with "nix-store --verify --check-contents" .


That's different though. that's verification _after_ the fact, whilst dm-verity does it any time during block-level access.

Also an attacker could modify the nix-store sqlite database and spoof the hashes, rendering this check moot




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: