4 ms·

On January 2014 Brendan Eich [1] called out for organization to build up a system to verify Firefox builds in order to secure the browser can't be used as an at

by zz1 12y ago

On January 2014 Brendan Eich [1] called out for organization to build up a system to verify Firefox builds in order to secure the browser can't be used as an attack vector being distributed with some malicious feature added to what's in the source code. Six months later nothing is done, that is because Firefox build are not deterministic yet. If you think this is an important issue, please vote this bug. Edit: [1] https://brendaneich.com/2014/01/trust-but-verify/ https://brendaneich.com/2014/01/trust-but-verify/

taeric 12y ago
I'm curious on the theoretical basis of this effort. I'm reminded of "On Trusting Trust." Simply put, not at all an easy problem to try and tackle. No, I'm not against trying. Just going from your thing, I'm not sure what is being aimed at. Specifically, would a "deterministic" build really help much? edit: I am perusing https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise https://blog.torproject.org/blog/deterministic-builds-part-o... and https://blog.torproject.org/blog/deterministic-builds-part-two-technical-details https://blog.torproject.org/blog/deterministic-builds-part-t... Good reads so far.
- zz1 12y ago
  On deterministic builds you may also find interesting this one: http://www.chromium.org/developers/testing/isolated-testing/deterministic-builds http://www.chromium.org/developers/testing/isolated-testing/...
  - taeric 12y ago
    That is about getting faster, not more secure. Right? I mean, I get that it is kind of nice to be able to verify that multiple sets of folks can build the same thing and compare results. I'm curious if there are any theoretical thoughts on how much this helps. For instance, it does not guarantee that there are not malicious changes in the codebase. Which is far more likely to be a problem, I would think. To that end, the entire browser war is ultimately counter security. As the vendors add more and more features, there are more and more places for malicious changes to hide. Not just in "mistakes," but in features that could be potentially misused. I feel that "deterministic builds" doesn't stem this that much. I'd love to be shown how/why I'm wrong.
    - walterbell 12y ago
      Depending on the browser component model, could you hash individual binary components? Over time, "base" components could stabilize in the same manner as long-term-support Linux kernels, with surgical patches for security fixes. I don't know how practical this would be with the component models for Firefox and Chromium.
      - taeric 12y ago
        Sounds somewhat reasonable; though, some long term support Linux installations were vulnerable to Heartbleed. And, especially with how far reaching some of the features of modern browsers are, the surface area for attacks is growing rather large.
- kbaker 12y ago
  Also this is an interesting link, Debian's ReproducibleBuilds effort: https://wiki.debian.org/ReproducibleBuilds#Why_do_we_want_reproducible_builds.3F https://wiki.debian.org/ReproducibleBuilds#Why_do_we_want_re...
- raving-richard 12y ago
  Please have a look at David A. Wheeler’s page on Trusting trust [1], including his 2009 PhD dissertation [2], where he clearly demonstrates that it is possible to have trusted (not in the MS sense...) computers (I think). You may also be interested in 'Countering "Trusting Trust"' on Schneier's website [3], which discusses a 2006 paper, also by Wheeler. [1] http://www.dwheeler.com/trusting-trust/ http://www.dwheeler.com/trusting-trust/ [2] http://www.dwheeler.com/trusting-trust/dissertation/html/wheeler-trusting-trust-ddc.html http://www.dwheeler.com/trusting-trust/dissertation/html/whe... [3] https://www.schneier.com/blog/archives/2006/01/countering_trus.html https://www.schneier.com/blog/archives/2006/01/countering_tr...
  - taeric 12y ago
    My memory on that was that it let you know whether you could trust your compiler. I couldn't remember if it extended ot the rest of the tool chain. Nor did I remember if it really hinged on deterministic builds. I'll have to retry it.
    - raving-richard 12y ago
      If you trust your compiler, then you can read the source code and then trust the compiled executable. If you are worried, then you can build the rest of your tool chain from source...
      - taeric 12y ago
        My point is that that is the heart of the trust. You have to establish that before you can use any "deterministic" builds of your utilities to establish their trust. Right?
    - dllthomas 12y ago
      Strictly speaking, it lets you know that your compiler binary matches its source. You can then read the source to decide if you trust the compiler (and others can audit it, can audit binaries generated from it, &c, &c). At which point, as raving-richard says, you can start to trust that your other utilities match their source as well. Which source also should be audited, &c, &c.

by zz1 12y ago

taeric 12y ago

I'm curious on the theoretical basis of this effort. I'm reminded of "On Trusting Trust." Simply put, not at all an easy problem to try and tackle. No, I'm not against trying. Just going from your thing, I'm not sure what is being aimed at. Specifically, would a "deterministic" build really help much? edit: I am perusing https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise https://blog.torproject.org/blog/deterministic-builds-part-o... and https://blog.torproject.org/blog/deterministic-builds-part-two-technical-details https://blog.torproject.org/blog/deterministic-builds-part-t... Good reads so far.

zz1 12y ago
On deterministic builds you may also find interesting this one: http://www.chromium.org/developers/testing/isolated-testing/deterministic-builds http://www.chromium.org/developers/testing/isolated-testing/...
- taeric 12y ago
  That is about getting faster, not more secure. Right? I mean, I get that it is kind of nice to be able to verify that multiple sets of folks can build the same thing and compare results. I'm curious if there are any theoretical thoughts on how much this helps. For instance, it does not guarantee that there are not malicious changes in the codebase. Which is far more likely to be a problem, I would think. To that end, the entire browser war is ultimately counter security. As the vendors add more and more features, there are more and more places for malicious changes to hide. Not just in "mistakes," but in features that could be potentially misused. I feel that "deterministic builds" doesn't stem this that much. I'd love to be shown how/why I'm wrong.
  - walterbell 12y ago
    Depending on the browser component model, could you hash individual binary components? Over time, "base" components could stabilize in the same manner as long-term-support Linux kernels, with surgical patches for security fixes. I don't know how practical this would be with the component models for Firefox and Chromium.
    - taeric 12y ago
      Sounds somewhat reasonable; though, some long term support Linux installations were vulnerable to Heartbleed. And, especially with how far reaching some of the features of modern browsers are, the surface area for attacks is growing rather large.
kbaker 12y ago
Also this is an interesting link, Debian's ReproducibleBuilds effort: https://wiki.debian.org/ReproducibleBuilds#Why_do_we_want_reproducible_builds.3F https://wiki.debian.org/ReproducibleBuilds#Why_do_we_want_re...
raving-richard 12y ago
Please have a look at David A. Wheeler’s page on Trusting trust [1], including his 2009 PhD dissertation [2], where he clearly demonstrates that it is possible to have trusted (not in the MS sense...) computers (I think). You may also be interested in 'Countering "Trusting Trust"' on Schneier's website [3], which discusses a 2006 paper, also by Wheeler. [1] http://www.dwheeler.com/trusting-trust/ http://www.dwheeler.com/trusting-trust/ [2] http://www.dwheeler.com/trusting-trust/dissertation/html/wheeler-trusting-trust-ddc.html http://www.dwheeler.com/trusting-trust/dissertation/html/whe... [3] https://www.schneier.com/blog/archives/2006/01/countering_trus.html https://www.schneier.com/blog/archives/2006/01/countering_tr...
- taeric 12y ago
  My memory on that was that it let you know whether you could trust your compiler. I couldn't remember if it extended ot the rest of the tool chain. Nor did I remember if it really hinged on deterministic builds. I'll have to retry it.
  - raving-richard 12y ago
    If you trust your compiler, then you can read the source code and then trust the compiled executable. If you are worried, then you can build the rest of your tool chain from source...
    - taeric 12y ago
      My point is that that is the heart of the trust. You have to establish that before you can use any "deterministic" builds of your utilities to establish their trust. Right?
  - dllthomas 12y ago
    Strictly speaking, it lets you know that your compiler binary matches its source. You can then read the source to decide if you trust the compiler (and others can audit it, can audit binaries generated from it, &c, &c). At which point, as raving-richard says, you can start to trust that your other utilities match their source as well. Which source also should be audited, &c, &c.