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
__ distcc mailing list http://distcc.samba.org/
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc
