[distcc] Security again

[Daniel Kegel]

Martin Pool wrote:
>>It would be nice if we could secure distcc without slowing it down,
>>as I believe ssh does.
> 
> Yes, SSH does slow it down.  A certain amount of slowdown is probably
> unavoidable compared to just blatting out bulk data over TCP, but it
> need not be so large.
> 
>>To avoid the overhead of repeatedly starting up ssl/ssh connections
>>and authenticating, it might be nice to cache connections for
>>reuse.
> 
> Yes.  I think key negotiation may also take several roundtrips.
> However, optimizing this needs to be done quite carefully to avoid
> introducing security holes.
> 
>>That'd mean having a resident connection daemon which either acts as
>>a proxy, or just passes an already-open socket to the distcc client
>>on request, and accepts it back from the client when it's done.
> 
>>I suspect this can't be done efficiently without cooperation
>>from both distcc and distccd.
> 
> This is question zero: does it need cooperation, or can it just plug
> in in place of ssh?  What causes your suspicions?

I guess it can plug in in place of ssh if you don't mind some slowness.
The two slowdowns I can imagine are:
1) the time to fork a wrapper that talks to the local daemon
2) the extra CPU time and latency of streaming input and output
files through the wrapper program
If it's a large file, there might be a noticable win in avoiding
the wrapper.

The 'ssh overhead' question is kind of moot now, since I'm becoming convinced
that ipsec is the way to go.  It'd handle the privacy
part just fine.  Still would want to kerberize distccd.
Which brings up the 'kerberized distcc' overhead question,
so perhaps it's not moot after all :-)

v Dan