begin quoting Andrew Lentvorski as of Thu, Sep 27, 2007 at 11:10:30PM -0700: > Joshua Penix wrote: > >On Sep 27, 2007, at 9:13 PM, John H. Robinson, IV wrote: > > > >>I have added the list of packages I installed in addition: > >> rcs, rsync, rtorrent, zsh > > > >rtorrent?? > > > >Please do be careful with bandwidth on this server... :) > > I would like to see rtorrent removed, actually. The codebase is > particularly bad (in spite of its claims) and running it is likely to > present some major security holes. It also has been banned at various > points for being particularly unsociable to trackers. > > I do realize that Bittorrent is becoming the de facto distribution > method lately and that we probably do need a bittorrent client. > However, one of the Python or Java-based ones are less likely to present > a security risk. If we truly need to go minimal (why?), Enhanced > Ctorrent should be good enough and far less likely to be hijacked.
The Java-based ones I've looked at are all unable to run securely in a JVM sandbox (limited disk access, full network access). The lure of using a custom classloader (rarely *actually* needed) is just too much. Of course, compared to a C program with no sandbox at all, this isn't an issue, I suspect. Can't bittorrent "dial down" the bandwidth? Or there's that user-space network library lets you control the bandwidth availability on a per-process basis -- we should be able to provide the functionality without the conconmitant network load. -- But an ncurses interface is so shiny! Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-steer
