4 ms·
Curious: What's the usual fix for this class of problem? Is it possible to flag certain bits of data as known-to-change and evaluate the rest of the build in is
by Karunamon 8y ago
Curious: What's the usual fix for this class of problem? Is it possible to flag certain bits of data as known-to-change and evaluate the rest of the build in isolation?
Example: Say you have a version string that outputs a build time. Can you hash the program with just that bit of string data marked as unknown (or that string table entry replaced with a placeholder, as far as our verifier is concerned) and verify the rest of the program is unchanged across builds?
- cldellow 8y agoIt varies by case. For the particular example of time, some common approaches are to hook the sys call for time such that it returns a constant value, or to teach your tool to output a constant value. The Nix thesis (https://nixos.org/~eelco/pubs/phd-thesis.pdf https://nixos.org/~eelco/pubs/phd-thesis.pdf) is a great read and goes through a bunch of these examples as part of its research.
- jefftk 8y agoTypically you just stop including the build time. It's a deterministic build, so why would the build time matter?
- lucb1e 8y agoI was going to say "because it's convenient", but I realized that you're right: if it's identical anyway, the release date is as good a timestamp of the code as you're going to get. If for some sysadmin reason the build time is relevant, file metadata can tell you.
- scruffyherder 8y agoMaybe I want to know that someone was messing with stuff, and even if they put something 'back in place' that matches, I may still want to know that it was built this morning and that something is going on. Of course code signing is going to mess that up.
- pjc50 8y agoThis only works in some limited circumstances; more often, the build differences cascade and produce a completely different result. For example, if the compiler puts full path names in intermediate object files, so on a different computer the object files have a different size, this may result in choosing a completely different layout for the binary.
- scarejunba 8y agoYou leave it out and go off revision hash or something. Back when we first introduced build times it was pre-modern-source-control. The Rev hash fulfils the function now.
- steveklabnik 8y agohttps://reproducible-builds.org/docs/ https://reproducible-builds.org/docs/ has a lot of strategies. For example, you could use the SOURCE_DATE_EPOCH environment variable, which if set, uses that value instead of the current actual time. This means that your normal builds do the normal thing, but you can configure the variable and get a reproducible build.
- jniedrauer 8y ago> Is it possible to flag certain bits of data as known-to-change and evaluate the rest of the build in isolation? This is what I do. I'm working with a hardware vendor that is not particularly security-conscious. I have to send them compiled binaries as part of a build pipeline, which they then modify in a non-deterministic way. Fortunately the changes are limited to data which has no impact on the function of the software. So I've created hashes of all the individual components that make up the binaries, and I skip hashing the parts that they modify. It's not ideal, but I can be reasonably confident that the binaries I compile function the same as the binaries that my hardware vendor distributes.
- anth_anm 8y agoYou fix the tools so that they work properly. You modify the compiler to always produce deterministic output (e.g. dummy timestamps).