Hi All! Actually, last time I was deploying distcc we had serious problems with the newly introduced security.
Personally, I would love to hear a case why the security in distcc (e.g. --allow) is needed at all. Distcc normally is deployed on corporate LAN which is already behind firewalls/etc. All the security doesn't help against possible abuses or simply incorrect scripts polling in tight loop servers. And that's are the problems which people are experience most often. Authentification? Accounting?? Why? This are only toy for admins and hurdle for people who use distcc. It is pretty pointless to put distcc on open net nor it is a usual deployment scenario. And even if you put distcc on open net, then you have much severe problem with your source code flying over the net, open to any cracker wishing to take a look inside. (*) I can't imagine company which would ever allow it. VPN is the proper solution, from my POV, making all the security enhancement in distcc (1) obsolete and (2) needless hurdle for users. (*) Or even worse case, when cracker hijacks the TCP connection and sends back to client the object file with rogue code embedded. I would never allow distcc on open net for the reason alone. On Wed, Jul 23, 2008 at 4:11 PM, Ian Baker <[EMAIL PROTECTED]> wrote: > Good afternoon to everyone. My name is Ian Baker and I'm currently at > CERN as a technical student working on the following enhancements/changes to > distcc: > > > User Authentication > > Implemented through the GSS-API and specified through a command line > argument to distcc, distccd will be initiated with the appropriate option. > Initially only mutual authentication will be implemented, at a later stage > confidentiality and integrity services may be optionally configurable if > this is something that's needed. > > > Service Discovery > > Existing Zeroconf mechanism with the advertisement of specific build > platforms for targeted builds. > > > Targeted Builds > > Command line argument to distcc which causes the appropriate subset of > servers to be extracted from the Zerconf services list. > > > Node Protection > > The --randomize flag should be turned on by default, with the possibility > of extending this behaviour over slots. > > > Monitoring and Accounting > > In addition to standard logging activity authentication information is to > be written to the distccd log files. A centralized service is to extract > these log files and parse their contents, possibly linked to an HTTP server > for > browser access. > > > > Questions and comments welcomed. > > Ian Baker > Technical Student > CERN > > > __ > distcc mailing list http://distcc.samba.org/ > To unsubscribe or change options: > https://lists.samba.org/mailman/listinfo/distcc > -- Трепет души если его боятся может обратится в страх. Но приняв его, он просто становится судьбой. -- Unknown Don't walk behind me, I may not lead. Don't walk in front of me, I may not follow. Just walk beside me and be my friend. -- Albert Camus (attributed to)
__ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/distcc