3 ms·

> The other problem is that making all binaries come out equal creates more of a monoculture that aids attacks on endpoints. This is a red herring, for two rea

by emaste 10y ago

> The other problem is that making all binaries come out equal creates more of a monoculture that aids attacks on endpoints. This is a red herring, for two reasons. First, even if the build is not reproducible, the distribution produces packages from some source code and those packages are fixed. If one is installing a distribution's binary packages there's no more or less of a monoculture if that package can be reproduced. Second, the sources of non-reproducibility we're trying to fix here come from things like timestamps embedded in the binaries, arbitrary directory file ordering, etc. These provide little to no meaningful diversity in the resulting binaries anyhow. Having the ability to reproducibly build packages does not preclude the application of tools or techniques to introduce diversity in the compilation process or otherwise obfuscate built binaries on one's own system.

nickpsecurity 10y ago
"This is a red herring, for two reasons. First, even if the build is not reproducible, the distribution produces packages from some source code and those packages are fixed. " That's not a red herring. That means the first distros will all start the same if a binary or be built from source (eg Gentoo). For the binary, they can build from source on local machine to immediately diversify then do the rest with source. This means the monoculture risk is only present when system is first set up. It can even be programmed to exclusively connect to repos until that risk is removed or warn the user if they turn that off manually. One could go further to even have multiple binaries available that each used a different, security technique or combo of them. All built into an automated, build system. "Second, the sources of non-reproducibility we're trying to fix here come from things like timestamps embedded in the binaries, arbitrary directory file ordering, etc. These provide little to no meaningful diversity in the resulting binaries anyhow." That's a red herring. The diversity I referred to came from compiler transformations that provably enhance security with site-specific obfuscations on top of that. Transformations that couldn't have happened if everyone's compile results in the same binary with hashes they're checking against each other. Those other things don't effect security much as you said. It's why I didn't bring them up. "Having the ability to reproducibly build packages does not preclude the application of tools or techniques to introduce diversity in the compilation process or otherwise obfuscate built binaries on one's own system." That much is true. However, solving the SCM problem + local, build tools already eliminates the need for the security aspect of it. The other techniques can then be included in by default. A reproducible build can also be done for any of it for extra benefits it brings but the compiler subversion is already knocked out by former techniques + a certifying compiler.
- emaste 10y ago
  > That's a red herring. The diversity I referred to came from compiler transformations that provably enhance security No. The work to get to a state where packages build reproducibly, in general, consists of removing timestamps, providing stable sort order for inputs, and similar cases. In the vast majority of cases the only diversity in a distro's package set comes from these sorts of differences. If addressing these cases results in a reproducible build, there was no meaningful diversity to begin with.
  - nickpsecurity 10y ago
    You keep focusing on this one set of changes you do in the process when it has absolutely nothing to do with what I'm saying about the security argument for doing reproducible builds, diverse compiles, binary checks, etc. The big picture of what you're doing with what attacks are likely to come in. If the goal is stopping subversion, I identified a bunch of other things you have to do. Some conflict with reproducible binaries where you avoid them or throw them away immediately. Some with strongest security... memory-safe languages, certified compilation, or highly-assured SCM... you aren't doing at all that I'm aware. Your attackers will try to hit all of this, though, rather than just do a compiler-compiler-subversion thing in MITM scenario. Hence the need for strong, holistic stuff instead of tactical hacks.
    - emaste 10y ago
      I'm sorry that we seem to be talking past each other. I don't disagree with what you write, my point is only that the reproducible builds effort has no real effect on aspects of it (such as binary diversity). Of course there's a lot more that needs to be done to prevent or detect malfeasance, and while it's related, it's beyond the scope of the reproducible builds effort.
      - nickpsecurity 10y ago
        We could be talking past each other a bit. Ill end the tangent in that case. I agree the diversity effect is contentious (a smaller claim) and possibly out of scope for people doing these projects.

by emaste 10y ago

nickpsecurity 10y ago

"This is a red herring, for two reasons. First, even if the build is not reproducible, the distribution produces packages from some source code and those packages are fixed. " That's not a red herring. That means the first distros will all start the same if a binary or be built from source (eg Gentoo). For the binary, they can build from source on local machine to immediately diversify then do the rest with source. This means the monoculture risk is only present when system is first set up. It can even be programmed to exclusively connect to repos until that risk is removed or warn the user if they turn that off manually. One could go further to even have multiple binaries available that each used a different, security technique or combo of them. All built into an automated, build system. "Second, the sources of non-reproducibility we're trying to fix here come from things like timestamps embedded in the binaries, arbitrary directory file ordering, etc. These provide little to no meaningful diversity in the resulting binaries anyhow." That's a red herring. The diversity I referred to came from compiler transformations that provably enhance security with site-specific obfuscations on top of that. Transformations that couldn't have happened if everyone's compile results in the same binary with hashes they're checking against each other. Those other things don't effect security much as you said. It's why I didn't bring them up. "Having the ability to reproducibly build packages does not preclude the application of tools or techniques to introduce diversity in the compilation process or otherwise obfuscate built binaries on one's own system." That much is true. However, solving the SCM problem + local, build tools already eliminates the need for the security aspect of it. The other techniques can then be included in by default. A reproducible build can also be done for any of it for extra benefits it brings but the compiler subversion is already knocked out by former techniques + a certifying compiler.

emaste 10y ago
> That's a red herring. The diversity I referred to came from compiler transformations that provably enhance security No. The work to get to a state where packages build reproducibly, in general, consists of removing timestamps, providing stable sort order for inputs, and similar cases. In the vast majority of cases the only diversity in a distro's package set comes from these sorts of differences. If addressing these cases results in a reproducible build, there was no meaningful diversity to begin with.
- nickpsecurity 10y ago
  You keep focusing on this one set of changes you do in the process when it has absolutely nothing to do with what I'm saying about the security argument for doing reproducible builds, diverse compiles, binary checks, etc. The big picture of what you're doing with what attacks are likely to come in. If the goal is stopping subversion, I identified a bunch of other things you have to do. Some conflict with reproducible binaries where you avoid them or throw them away immediately. Some with strongest security... memory-safe languages, certified compilation, or highly-assured SCM... you aren't doing at all that I'm aware. Your attackers will try to hit all of this, though, rather than just do a compiler-compiler-subversion thing in MITM scenario. Hence the need for strong, holistic stuff instead of tactical hacks.
  - emaste 10y ago
    I'm sorry that we seem to be talking past each other. I don't disagree with what you write, my point is only that the reproducible builds effort has no real effect on aspects of it (such as binary diversity). Of course there's a lot more that needs to be done to prevent or detect malfeasance, and while it's related, it's beyond the scope of the reproducible builds effort.
    - nickpsecurity 10y ago
      We could be talking past each other a bit. Ill end the tangent in that case. I agree the diversity effect is contentious (a smaller claim) and possibly out of scope for people doing these projects.