4 ms·
I wasn't referring to Nix, how Nix uses hashing, what specific hash, or source implementation it is using, or that it might be using an artefact hash. I was ref
by oneplane 3y ago
I wasn't referring to Nix, how Nix uses hashing, what specific hash, or source implementation it is using, or that it might be using an artefact hash. I was referring to the referencing method: a hash. This is the same method in the three mentioned products (nix, docker, vagrant): an immutable pointer to a specific resource.
As for CI, dev environments, not relevant here. I only mentioned in passing because CI is a common use case for hardcoded immutable reference. We're talking about someone wanting a box to experiment in, not CI. Not even software engineering either.
- kreetx 3y agoWhat hashes do you use in docker or vagrant?
- oneplane 3y agoSHA256, generally. So for example, you might use 5c15a6e5c0bf02e6c0eaa939cb543c41d7725453064c920b9a4faeea7c357506. (This is a digest hash you'd use in Docker, as an example) You can both consume that specific one, but also reproduce it locally if you want to. Depending on your intent, bandwidth and trust you can pick the method you desire.
- kreetx 3y agoI mean hashes of what, not which hash algorithm. If you build the same Dockerfile, then I don't think you'll get the same hash, so I'm not sure what the use of that hash would be. (Did you mesn a hash of some other thing?)
- nunez 3y agoSee my post above. Those hashes are a checksum of the image as seen by the registry plus some additional magic.
- kreetx 3y agoYes, but every other thing you install in the container you'd somehow need to manage the hashes for, too.
- oneplane 3y agoThe hash of the image. So you cannot get the same hash if you change something in the image. This is also why you have reproducible builds, the source should always result in the same hash, otherwise the build would not be reproducible. So building the same Dockerfile twice gets you the same hash. This does of course not work if you change something each build, like pulling in some random dependencies that you didn't also pin to a hash, or if you don't use a fixed point in time for the filesystem. We also sign the images so you get some protection against (future) hash collisions. Works for about 900 different images in our internal registries so far. We also used nix, but only a handful of developers actually enjoyed it, so that project got killed off. You can use any search engine and search for "Dockerfile reproducible build" if you want to learn more.
- kreetx 3y agoYou get the same hash only if you build the image when none of your dependencies were updated in the mean time. If you `apt-get install something` in a month, the resulting image will most likely not have the same hash. Docker itself doesn't really get you reproducible builds. I assume you haven't actually tried to achieve it if you still believe it. Docker is like any arbitrary linux machine you start installing things on: you need some other system to get reproducibility.
- oneplane 3y agoWe have used reproducible builds for many years, and we haven't had issues with it. Of course you're going to get random results when you issue random commands (like apt-get install), which is why you don't do that if you want reproducible builds. It's also not a normal workflow to build the same image many times, except for validation, and you do that with frozen sources, not arbitrary references. You build the image, sign it, distribute it. It doesn't get rebuilt on the destination.
- kreetx 3y agoHow do you do reproducible builds at the moment?