7 ms·

The chain of trust doesn't quite stop at compiling the source, in order to be really sure that nothing unintended is going on you have to compile the compiler y

The chain of trust doesn't quite stop at compiling the source, in order to be really sure that nothing unintended is going on you have to compile the compiler yourself. At the end of the day you will have to trust some bootstrapping binary compiler unless you put it together yourself in machine language.

avz 12y ago
Good point. Given sufficient paranoia this train of suspicion can be continued even deeper down the rabbit hole: you'd need to inspect the hardware designs and make sure the hardware you've got was actually produced according to the inspected designs. In technology as elsewhere, it seems life is ultimately based on trust in someone.
- holri 12y ago
  > In technology as elsewhere, it seems life is ultimately based on trust in someone. trust is a function of control. With free software it is distributed trust and control. With proprietary Sw it is centralized trust and control. Real life proved that centralized control is a bad idea, that is why we invented democracy and free software.
  - avz 12y ago
    Trust is a function of the expected incentives of the trusted. One way to manage their incentives is by exercising control, but there are other more friendly ways, too. For example, shared goals, community, reputation, financial rewards, reciprocity and ethics standards all provide weaker or stronger reasons to trust others.
M2Ys4U 12y ago
Actually, you don't. You can use two different compilers that compile each other to prove that the compilation won't be tampered with. See https://www.schneier.com/blog/archives/2006/01/countering_trus.html https://www.schneier.com/blog/archives/2006/01/countering_tr...
- kijin 12y ago
  What if both compilers are backdoored? It's not like you have a large choice of good compilers for any given language/platform pair.
  - schoen 12y ago
    Schneier's summary of Wheeler's method says: "This countermeasure will only fail if both [compilers] are infected in exactly the same way. The second compiler can be malicious; it just has to be malicious in some different way: i.e., it can't have the same triggers and payloads of the first. You can greatly increase the odds that the triggers/payloads are not identical by increasing diversity: using a compiler from a different era, on a different platform, without a common heritage, transforming the code, etc."
oneeyedpigeon 12y ago
Contrariwise, the nefarious app has to trust that I haven't got a whole bunch of purposefully misleading data that I'm feeding it.

avz 12y ago

Good point. Given sufficient paranoia this train of suspicion can be continued even deeper down the rabbit hole: you'd need to inspect the hardware designs and make sure the hardware you've got was actually produced according to the inspected designs. In technology as elsewhere, it seems life is ultimately based on trust in someone.

holri 12y ago
> In technology as elsewhere, it seems life is ultimately based on trust in someone. trust is a function of control. With free software it is distributed trust and control. With proprietary Sw it is centralized trust and control. Real life proved that centralized control is a bad idea, that is why we invented democracy and free software.
- avz 12y ago
  Trust is a function of the expected incentives of the trusted. One way to manage their incentives is by exercising control, but there are other more friendly ways, too. For example, shared goals, community, reputation, financial rewards, reciprocity and ethics standards all provide weaker or stronger reasons to trust others.

M2Ys4U 12y ago

Actually, you don't. You can use two different compilers that compile each other to prove that the compilation won't be tampered with. See https://www.schneier.com/blog/archives/2006/01/countering_trus.html https://www.schneier.com/blog/archives/2006/01/countering_tr...

kijin 12y ago
What if both compilers are backdoored? It's not like you have a large choice of good compilers for any given language/platform pair.
- schoen 12y ago
  Schneier's summary of Wheeler's method says: "This countermeasure will only fail if both [compilers] are infected in exactly the same way. The second compiler can be malicious; it just has to be malicious in some different way: i.e., it can't have the same triggers and payloads of the first. You can greatly increase the odds that the triggers/payloads are not identical by increasing diversity: using a compiler from a different era, on a different platform, without a common heritage, transforming the code, etc."

oneeyedpigeon 12y ago

Contrariwise, the nefarious app has to trust that I haven't got a whole bunch of purposefully misleading data that I'm feeding it.