On 2 Apr 2004, Dan Kegel <[EMAIL PROTECTED]> wrote: > http://distcc.samba.org/security.html gives a good overview of > distcc's security situation. > Apple's Rendezvous patches, I believe, open up even more security holes. > > Kerberos is fairly widely deployed (at least by Active Directory). > It is somewhat tempting to kerberize distcc to try to protect > the distcc servers from being hacked by unauthorized users' input, > and to ssl-enable distcc to try to protect authorized users' source > code from prying eyes. >
> 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? -- Martin
signature.asc
Description: Digital signature
__ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc