Hacker News Reader

Comment by zz1 | Hacker News Reader

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/

View on HN

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-o... and https://blog.torproject.org/blog/deterministic-builds-part-t... Good reads so far.

On deterministic builds you may also find interesting this one: http://www.chromium.org/developers/testing/isolated-testing/...

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.

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.

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.

Also this is an interesting link, Debian's ReproducibleBuilds effort:

https://wiki.debian.org/ReproducibleBuilds#Why_do_we_want_re...

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/ [2] http://www.dwheeler.com/trusting-trust/dissertation/html/whe... [3] https://www.schneier.com/blog/archives/2006/01/countering_tr...

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.

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...

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?

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.

Right, my point is having deterministic builds of firefox aren't even really needed for this. If you trust your compiler, you trust your compiler. What does it matter if you have a non-deterministic build of a utility. You trust what is non-deterministically building it.

As this stands, if you deterministically build firefox, you just know that if your toolchain is corrupted, it is consistent. :)

Right?

If you trust your compiler you can verify that your build is the safely based on the source that you have. If the build is deterministic then you could verify that the binary being distributed to the masses isn't compromised by building the same file yourself and seeing that it is the same.

Right, and my question is essentially if this is "putting the cart before the horse." Do Mozilla have efforts in place to establish trust of their compilers? (I expanded on my response below. I really wish I knew the correct way to "merge" conversation trees here. Is there a good protocol for that?)

esrauch has it, but it's a point worth stressing: it gives many more people the opportunity to notice any discrepancy in common tool chains, as well as adding assurance for those who aren't building their own.

I can see how it helps. I'm still curious by how much. Consider, if everyone's common tool chain is untrustworthy, then this solves nothing.

This is why the "docker" idea worries me. It is basically counter productive. Just moves the "trust" to a whole harder thing to verify.

And the reason I was focusing on the compiler point, is to my knowledge nobody has established that the common compilers are trustworthy. At least not the ones in use at large. Until that happens, we're back to my first point. Which is to say that we may not be trustworthy.

Again, to be clear, I see there is benefit to knowing that we are all of the same trustworthiness. Having "reproducible" builds that don't match is an indication that something is definitely wrong. Definitely a worthy effort. Just, having reproducible builds that do match doesn't really tell you much about the trustworthiness of the application. Specifically, it only tells you that it is as trustworthy as another build. (Similar to the boolean logic that trips folks up all of the time that False \implies True is true, as is False \implies False.)

Unless, of course, I'm still misunderstanding something.

"Consider, if everyone's common tool chain is untrustworthy, then this solves nothing."

I don't quite agree - it more clearly establishes what tool chain people should be auditing!

I had to think about this for more than a second. :) I think I see what you mean. Specifically, if N = 2, this doesn't do much. However, as soon as you have more folks that agree, then the first time someone disagrees, you have a good spot for auditing. Right?

I still can't see how the docker idea helps this purpose right off.

This is a good talk regarding "Trusting Trust" for binary toolchains http://youtu.be/QogdeTy7cDc

A C compiler is not a single executable. If you take gcc, compiling C code involves a preprocessor, a compiler, an assembler and a linker (and that's a.simplified view). To make matters worse, the assembler and the linker are not even part of the GCC source code, they're a separate project. That would likely make the process of DDC significantly more difficult than if the compiler was actually a single executable. Also, there are other things involved in the whole process, like the CRT static objects, dynamic libraries and the dynamic loader. That's many more items to trust. You could even add the kernel to the list.

Reply on news.ycombinator.com