[distcc] A way to validate the distcc setup?

[Martin Pool]

On 26 May 2003, Oscar Fudd <ofudd at speed-test.net> wrote:

> Do you know if the linux kernel will work right if you use a mix of
> compilers to make it?

No, it will not.  However the different compiler behaviour in some
cases only matters to particular files which switch based on the gcc
version.  If we didn't happen to check those files, then we might
think the build was OK when it actually was not.  Short of building
every file in two places, which obviously defeats the purpose, then
there is not much that can be done.

I am open to suggestions about simple things distcc can do to try to
make sure compiler versions are OK, but in the end it looks like the
responsibility is on the user.

> > Is this an actual problem for you, or just an idea?  If you have flaky
> > memory then you have bigger problems.  For most people once they get
> > the right version of the compiler installed then things don't
> > magically break.
> 
> Just an idea.  I was trying to speed up my kernel compile, and failed
> miserably, although distcc doesn't seem to be the cause.
> 
> > Don't fool yourself that you could catch malicious servers.
> 
> Why not?  Doesn't the Seti system catch malicious servers?

That's a good question, but the situation is quite different.

If somebody feeds back false results to Seti then the worst that can
happen is that Seti might not see a signal that is actually there.  If
somebody sends you a bad binary over distcc then they could easily own
your box.

Conversely, all an attacker has to gain from faking Seti is a high
ranking, so the risk of discovery and banning is a sufficient
disincentive.  They have to fake many many blocks to achieve a high
ranking.  But the "reward" for breaking into a distcc client is
potentially higher, and it can be done with just one corrupted object
file.

In addition Seti are not in any particular rush to get their results.  
Running every block twice, or a large percentage of blocks repeatedly
is not a big deal.  Making distcc compilation twice as slow would make
it impractical for many people.

Finally distcc is probably not practical for planet-scale distribution
like Seti at home, because the networks are too slow, most makefiles
cannot issue thousands of jobs, and the client would be overwhelmed.
So for most practical situations all the participating machines are
likely to be in the same building and probably owned by the same
person/family/organization.  So if somebody tries to screw with your
build you can just punch them. ;-)

-- 
Martin