4 ms·

At the core of this issue is reproducibility. If you can fully reproduce the software you use, you no longer need to trust that X binary/container was built pro

At the core of this issue is reproducibility. If you can fully reproduce the software you use, you no longer need to trust that X binary/container was built properly (although you still need to trust the source code itself, as well as the source of the source code). You can also always rebuild your software with newer dependencies (e.g. if they have received security updates). It is about time we embraced Guix/Nix.

jacques_chester 6y ago
I don't agree (or rather, I don't think it's the only option). Reproducibility is necessary when you are unable to trust the accuracy and integrity graph leading up to a particular asset. But if you have a trusted, exhaustive, tamper-resistant history of how an asset came to be, you can skip a rebuild altogether.
- cbaines 6y ago
  In terms of an asset being software that you're deploying, I don't get this attitute. If the process for producing the software is unreproducible, then you're running the risk that the behaviour of the software will be unreproducible. As in you run the generation process once, and then again with the same inputs, and you'll get an output that works differently. Now of course you can store the generated asset, which gives some certainty in the roll back case. But roll backs are hopefully rare, what's more common is to make small changes to inputs (like source code changes), and hope that the generate asset has only been affected by the intended change. To give an example of how this works where no care has been taken that the process is reproducible, I've seen people try to make code changes to Docker images, and end up with changes that they didn't intend (like a different version of Debian in the image, or a different Ruby/Python version).
  - jacques_chester 6y ago
    I think I misunderstood your emphasis. I've seen folks position reproducible builds as the best and only solution to trust and integrity problems; I buttonholed you as the same. I do appreciate the general benefits of controlling the factors which go into an asset. Build reproducibility is a standard that requires a high capability to track and control your assets. In that respect it's an excellent goal. Recapping: I say yes to reproducibility as a practice, but I don't see it as a substitute for an accounting mechanism. They're complementary.

jacques_chester 6y ago

I don't agree (or rather, I don't think it's the only option). Reproducibility is necessary when you are unable to trust the accuracy and integrity graph leading up to a particular asset. But if you have a trusted, exhaustive, tamper-resistant history of how an asset came to be, you can skip a rebuild altogether.

cbaines 6y ago
In terms of an asset being software that you're deploying, I don't get this attitute. If the process for producing the software is unreproducible, then you're running the risk that the behaviour of the software will be unreproducible. As in you run the generation process once, and then again with the same inputs, and you'll get an output that works differently. Now of course you can store the generated asset, which gives some certainty in the roll back case. But roll backs are hopefully rare, what's more common is to make small changes to inputs (like source code changes), and hope that the generate asset has only been affected by the intended change. To give an example of how this works where no care has been taken that the process is reproducible, I've seen people try to make code changes to Docker images, and end up with changes that they didn't intend (like a different version of Debian in the image, or a different Ruby/Python version).
- jacques_chester 6y ago
  I think I misunderstood your emphasis. I've seen folks position reproducible builds as the best and only solution to trust and integrity problems; I buttonholed you as the same. I do appreciate the general benefits of controlling the factors which go into an asset. Build reproducibility is a standard that requires a high capability to track and control your assets. In that respect it's an excellent goal. Recapping: I say yes to reproducibility as a practice, but I don't see it as a substitute for an accounting mechanism. They're complementary.