On Wednesday 23 October 2002 07:26, Nathan Russell wrote: > >Other people have mentioned the possibility of "automatically" disengaging > > or updating the client. > > I am aware of several linux distributions which do the exact same > thing (in fact I am not aware of any widely popular one which > doesn't).
Eh? I'm not aware of any major OS which even attempts to automatically install upgrades, with the exception of Win 2000 (if you applied SP3 and forgot to disable automatic updating) and Win XP (if you applied SP1 and forgot to disable automatic updating). The problem here is one of _control_. If you allow someone else - whatever their intentions are - to install & run software on your system without your explicit permission on a case-by-case basis, you are effectively handing over full control of your system & all the data on it to someone else. > > However, they require the user to initiate the update. Ah, I see what you mean. > Would you be > more comfortable if that was done, as well as some sort of signature > on the update files? Here's the difference: when I'm updating my (Red Hat) linux systems, _I_ wrote the script that downloads the update files (from a local mirror of my choice) & checks the certificates. Only then do I trust someone else's software to unpack and apply the updates. I'd far rather run an unpatched, insecure service than depend on something that is in principle uncheckable to download & install software automatically. The problem is that, if the connection can be hacked in to, an attacker can supply anything they like .... Better still if I just download the source code & compile it myself. That way I am absolutely sure that what I use is what I think I'm using. Obviously this principle can apply only to programs which are 100% open source. But here's the crunch: this discussion is related to the current problems with seriously obsolete clients. By definition these do not contain auto-update code, so the discussion is (+/-) pointless. To fix the problems, we really need to take a "belt and braces" approach: (1) the server needs to protect itself from "machine gun" requests. I reckon the best way to do this is for the server to detect continuous repeat requests & automatically command its firewall to block data from that source address for a limited time (say one hour). This would protect the server from excess load, yet is not exploitable by remote attackers - all they can do is temporarily block themselves out! Although not neccessary to the project, I'd reccomend that the blocking action be logged so that it can be followed up (manually or automatically) by contacting the user concerned. Actual contact may sometimes not be possible because the registered user no longer controls the system. (2) future clients should be modified so that, if PrimeNet has no suitable work to allocate, they back off for a few hours before trying again. Even if this means running out of work altogether - though, given the "days of work" parameter, they should run "in need of more work" for some time before finishing the current assignment. In addition the server probably would benefit from addition of "intelligence" so that it does not attempt to assign work which specific versions of the client cannot accept. However, the action I suggest under (1) alone is sufficient; no automatic or forced upgrade is _required_. Regards Brian Beesley _________________________________________________________________________ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
