copper_rose's comments

Does the reproducible builds project have a hand in the project to give Security/Binary Transparency to Firefox? I ask because i don't know, and I saw no language to suggest that in the page linked.

Thank you for the clarification. I can see from your examples why binary transparency is a useful concept worth considering in its own right. I still suspect there is a huge amount of overlap between the problems the author is trying to solve and they ones that Nix/Guix has already solved (especially the way they want to use a hashing algorithm to identify the release). I'll bet a general solution for binary transparency could be built - a solution from which practically all software in general could benefit, not just Firefox in particular - by building on top of (or at least learning from) the base that the purely functional software deployment model, as pioneered by Nix, has already given us.

I am not simply saying "They should use Nix" as if that would magically accomplish their goals. I am saying that they could build on top of, or at least learn from, the novel techniques that Nix has contributed to the field of software deployment.

Nix's functional software deployment model is a useful tool for building software reproducibly, but reproducible builds are neither the primary motivation for nor the primary goal of the Nix model. For information on what problems it aims to solve, how it solves them, and how it can be applied in various useful ways (e.g., a package manager is just one particular thing you can implement using the Nix model), I suggest you read the first chapter of the thesis I linked earlier. It's very interesting, and I think you'll find that the model can be applied to problems like this; it's not just about building software reproducibly, although software that builds reproducibly is conducive to the model.

I can understand why those scenarios would be concerning. Ultimately, what matters depends on the threat model. I believe that the Nix model can be used as a base for solving issues like the one presented here, and that it can be done in generality, for a wide spectrum of software.

The stated goal is to enable someone to verify "that they have gotten the same version as the rest of the world and not a special, possibly compromised version." This is actually two goals: (1) verify that your version is the same as everyone else's, and (2) verify that that version is genuine.

Why should one care about (1)? All that really matters is (2). As long as I'm using a genuine release, does it matter what the rest of the world is using? Unless I wish to establish trust in a binary based on how popular it is, or unless I care about interoperability between the version I have and the version others have, it doesn't really matter what version everyone else has.

I wonder if the author has heard about Nix or Guix? The purely functional software deployment model pioneered by Nix solves (2) trivially, for practically all applications in general, not just Firefox specifically. It also solves many other problems in the field of software deployment that this article doesn't even mention.

Long story short, don't reinvent the wheel. Use Nix or Guix. Learn more by reading the first chapter of Eelco Dolstra's thesis, which describes the problems and how the Nix model solves them:

https://nixos.org/~eelco/pubs/phd-thesis.pdf

Edit: Even if one is concerned about (1), the Nix model enables ways to verify that the origin is actually sending a binary that was built from the source it claims to use. For example, consider "guix challenge":

https://www.gnu.org/software/guix/manual/html_node/Invoking-...

Yikes. All those nines of durability that Amazon provided for Dropbox...brought to naught by a bug in Dropbox's software.

The problem is that in many server environments, particularly at scale, the speed of the bootstrap processes of the OS doesn't matter. One of the goals of systemd is to make the bootstrap process faster, which is irrelevant for those (non-desktop) use cases. So you see, systemd is solving problems, and making trade-offs to do it, that just don't matter for the non-desktop use case. I can of course choose not to install gdm, but that doesn't change the fact that systemd was designed (you might say over-designed) with the desktop use case in mind. Because of that, I have to live with those trade offs, even though my use case does not benefit. Since all major Linux distros are deciding to adopt systemd, it will be very difficult to "roll your own" and use something else, especially since the rest of the userland will assume that everyone is doing things the systemd way, this making it even harder to go against the flow.

He's hit the nail on the head - systemd's fundamental design is not appropriate for the server environment:

"I have to provide a system that runs reliably and can easily be reasoned about and yet I have to build it on distributions created by people who consider how long it takes to get to the fucking GDM login screen and if shutting the laptop lid will cause the system to hibernate properly or not."