Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
Reproducible builds are an important part of efforts to secure the software supply chain. Ideally you want multiple independent parties vouching that a given package (whether a compiled binary, or a source tarball) corresponds to a globally immutably published revision in a source code repository.
That gives you Binary Transparency, which is already being attempted in the Arch Linux package ecosystem[0], and it protects the user from compromised build environments and software updates that are targeted at a specific user or that occur without upstream's knowledge.
Once updates can be tied securely to version control tags, it is possible to add something like Crev[1] to allow distributed auditing of source code changes. That still leaves open the questions of who to trust for audits, and how to fund that auditing work, but it greatly mitigates other classes of attack.
[0] https://github.com/kpcyrd/pacman-bintrans
[1] https://github.com/crev-dev/cargo-crev
Reproducible builds are an important part of efforts to secure the software supply chain. Ideally you want multiple independent parties vouching that a given package (whether a compiled binary, or a source tarball) corresponds to a globally immutably published revision in a source code repository.
That gives you Binary Transparency, which is already being attempted in the Arch Linux package ecosystem[0], and it protects the user from compromised build environments and software updates that are targeted at a specific user or that occur without upstream's knowledge.
Once updates can be tied securely to version control tags, it is possible to add something like Crev[1] to allow distributed auditing of source code changes. That still leaves open the questions of who to trust for audits, and how to fund that auditing work, but it greatly mitigates other classes of attack.
[0] https://github.com/kpcyrd/pacman-bintrans
[1] https://github.com/crev-dev/cargo-crev
Depends on how the state is stored. If it's in configuration, Nix generated it and it lives immutable in the Nix store, so Nix will just point out it to the old version on rollback.
If it's something like the content of a SQL database, which lives outside the Nix store and which Nix did not generate, you need some other tool (like a filesystem snapshot, maybe) to perform the rollback. I think CoW filesystems sometimes have performance issues with DBs, though, so I'm not sure that's always the approach you'd take.
The Nix ecosystem does have a fairly mature tool for managing stateful components that live outside the Nix store, though: https://github.com/svanderburg/dysnomia
It's been around for a long time. Idk who all is using it
One of the nice things about the FSF's free software principles is that if you disagree with how they think you should use their software, they're not going to stop you. Nonguix[1] provides solid non-free support if that's what you want.
The FSF even condones non-free software (in a rather dorky way) for people whose machines require it[2]. I understand the FSF's principles and am glad they hold to them so strongly, but I would use non-free graphics drivers if I were to install Guix. I do fundamentally agree with the principles of software freedom and I am honest with myself that I am in fact making a moral compromise. Similarly I'd probably compromise over CPU microcode patches, even though I believe I have the moral right to view, understand, and change those microcode updates if I wish to and am displeased that my rights are being violated.
I believe in this day and age where the right to repair your own equipment is under serious threat, the principle that we should be free to modify the machines we own as we see fit is more important than ever.
[1] https://gitlab.com/nonguix/nonguix
[2] https://www.gnu.org/philosophy/install-fest-devil.en.html
Is it anymore of a "magic incantation" than the linux-image-XYZ package which controls which OS kernel is installed?
If you want to see when Intel issues new microcode updates, it is all available on their GitHub: https://github.com/intel/Intel-Linux-Processor-Microcode-Dat...
Is it anymore of a "magic incantation" than the linux-image-XYZ package which controls which OS kernel is installed?
If you want to see when Intel issues new microcode updates, it is all available on their GitHub: https://github.com/intel/Intel-Linux-Processor-Microcode-Dat...
* having to rebuild some packages that are not part of your main OS configuration because you upgraded your main OS (e.g., Arch updates breaking AUR packages, or system upgrades breaking software you compiled manually or your Python virtualenvs, etc.). (You do have to inform the package manager that you don't want these externally-depended-on packages garbage collected, though. For Nix, for example, you can do that automagically by running fc-userscan against your project directories: https://github.com/flyingcircusio/userscan )
The statelessness is related to reproducibility in that it's a result of the functional package management approach to reproducibility. Since every version of your whole system is generated without reference to previous versions (indeed, from scratch!), the OS never has to navigate state transitions for its packages. It doesn't have to worry about converting configuration files from one format to another, or replacing defaults, or the implicit dependencies of your system undergoing name changes or being replaced. Nix and Guix don't need Debian-style transitional packages and similar tricks. That means you aren't punished, on a per-package basis, for not updating your system constantly.
For example, I recently took some neglected, non-internet-facing NixOS servers and updated them from an early 2018 release of NixOS to the latest NixOS unstable rolling release. While I did have to first work a forward incompatibility issue in Nix itself, the rest of the upgrade was a single step, and I didn't have to worry about finding a valid ‘upgrade path’.
It's worth noting that in a strict sense, the reproducibility is all still there, even for NixOS releases that no longer receive updates. If you need to use an old version of some piece of software for compatibility reasons, in a safe environment, you can use the latest and greatest Nix to install packages from NixOS releases that are 2 or 4 or 6 or 8 years old— including on top of a bleeding edge system running NixOS Unstable.
But you have a point: it would be awesome if there were long-term releases, you would get a different kind of reproducibility— one which is less strict but more useful in some ways. For example, you could take a Nix expression that someone posted in a Gist on GitHub 4 years ago, for what was back then the latest NixOS stable release. If that release were also an LTS, you could not just reproduce what they actually had, but apply it against the latest version of the same LTS to get a system that should be totally compatible in terms of behavior, but suitable for running in production without modification, thanks to up-to-date security patches.