Given the choice between reproducible and the scattered disasters I've seen, reproducible seems better.
But I would be content with "pipelined", and have the readily automated part handle itself.
You don’t need reproducible builds
61–70 of 179 posts
Re: You don’t need reproducible builds
#62I think OP is coming from a different perspective than I (corporate bespoke solution builder) do. When I say "reproducible build" I mean a build that is the same on any machine (i.e. no special magic necessary to build a "official" version of the code). Too often in corporate environments, getting a local build or setting up a new build pipeline involves arcane black magic and/or copy/pasting weird libraries that can…
For this reason I’ve been dockerizing my builds for almost five years. I was late to the Docker party, but when I saw the benefits it brings to build pipelines, I was sold. It's true that a dockerized build isn’t any simpler than its non-dockerized ancestor, but at least there’s a Dockerfile that lays bare all the black magic and special sauce which goes into each build. And it can be version controlled to watch for…
While Docker can be very useful against attempts to "download the internet" (possibly simulating multiple remote servers on a fake network) and aganst accidental changes to source files, configurations and tools, there are sources of intentional nonreproducibility (e.g. embedded timestamps, common in Windows executables) that need to be addressed more directly.
Re: You don’t need reproducible builds
#63Reproducible builds, combined with digital signatures and an append-only cryptographic ledger, solve a lot of these trust issues.
https://paragonie.com/blog/2016/10/guide-automatic-security-...
Re: You don’t need reproducible builds
#64There are a lot of reasons to prefer reproducible builds, and many of them are not security related... It seems a bit presumptuous to argue that noone needs reproducible builds because one particular security argument is flawed. First, a non-flawed security argument: it only takes one non-malicious person to build a package from source and find that it doesn't match the distributed binary to spot a problem. Sure, if…
> - If a particular version of the code is tested, and the binary is not a pure function of the code, then you haven't really tested the binary. Bugs could still be introduced that were not caught during testing because your build is non-deterministic.
This is a weaker argument IMO because when building for test, generally, all optimizations are disabled, debug info is emitted, symbols are un-stripped, and so on. The unit under test is usually very different from the shipped artifact even at the module level. Not least because the test functions are compiled in.
Re: You don’t need reproducible builds
#65I dont think that reproducible builds are perfect or solve every problem. I still think they are worthwhile though because they allow for a better audit trail, and every step that is auditable makes it easier to pinpoint at what step something bad happened.
Sure users arent likely to verify them. I still think there is value in after the fact being able to determine - clearly this binary came from this source code artifact vs clearly this binary was substituted as it doesnt match the source code. Its not perfect but it helps reduce the places where an attack can take place with nobody noticing.
Re: You don’t need reproducible builds
#66There are a lot of reasons to prefer reproducible builds, and many of them are not security related... It seems a bit presumptuous to argue that noone needs reproducible builds because one particular security argument is flawed. First, a non-flawed security argument: it only takes one non-malicious person to build a package from source and find that it doesn't match the distributed binary to spot a problem. Sure, if…
Reproducible builds make diagnosing performance regressions less horrible, because they are less likely to have been caused by random shuffling of code, and any random shuffling is reproducible when trying to bisect.
Re: You don’t need reproducible builds
#67Well, after spending so much time watching kilometers of rolling text on my screen while `emerge -uavDN @world` compiles everything, I agree I don’t need reproducible builds
Re: You don’t need reproducible builds
#68There are a lot of reasons to prefer reproducible builds, and many of them are not security related... It seems a bit presumptuous to argue that noone needs reproducible builds because one particular security argument is flawed. First, a non-flawed security argument: it only takes one non-malicious person to build a package from source and find that it doesn't match the distributed binary to spot a problem. Sure, if…
Reproducible builds also tend to create isolation. I.e. if I compile one C file, change another, the compilation of the second one usually doesnt affect the first. This is useful when trying to debug code. E.g. I can add print statements to callers to get more info surrounding a bug when in a non-reproducible state, the recompilation itself may have eliminated the bug.
Re: You don’t need reproducible builds
#69Too many people in this thread are mixing build systems vs security. The author is talking about Reproducible builds about security and only security[0]. https://en.wikipedia.org/wiki/Reproducible_builds
[deleted]
Re: You don’t need reproducible builds
#70There are a lot of reasons to prefer reproducible builds, and many of them are not security related... It seems a bit presumptuous to argue that noone needs reproducible builds because one particular security argument is flawed. First, a non-flawed security argument: it only takes one non-malicious person to build a package from source and find that it doesn't match the distributed binary to spot a problem. Sure, if…
> - If a particular version of the code is tested, and the binary is not a pure function of the code, then you haven't really tested the binary. Bugs could still be introduced that were not caught during testing because your build is non-deterministic. This is a weaker argument IMO because when building for test, generally, all optimizations are disabled, debug info is emitted, symbols are un-stripped, and so on. The…
If that's really what you are doing, then you are doing it horribly wrong.