OK, you got me. I overstated this point. A better way of expressing it would be that I wouldn't post viral code to a public forum for moral reasons.
Now I'd like to clarify my position, so the rest of this isn't really in reply to srawls.
I'd like to note that I'm against a ban on posting viral code to public forums and I wasn't trying to play the one-man ban here. My removal of the code was always a short-term action in my mind (and one that I didn't make before getting support from other editors). I am strongly against posting of viral code to public forums and I am strongly against banning the posting of viral code to public forums.
I'll also admit to not having seen the obfuscated version of the code nor of having done more than glance at the code in this thread. When I said that I didn't find the code interesting, it didn't have to do with the quality of the code. I didn't find the details of how to do what was described rather well in the text to be interesting.
As for how to protect against this, I think the standard methods for protecting against Unix exploits apply. (I don't much buy into the "filter/scanner" approach that is so common on Windows systems -- it is a poor "patch" to fundamentally flawed system.)
I think you should have your code in directories that can't be written to in files that you don't own and that you shouldn't do much of anything as "root". I think changing system files should require a password. I think you should have a separate system to check for and track changes to system files. TripWire is a good example of this.
For example, I usually have a source code control system that covers system files and an "install" procedure that requires a password in order to get the privilege to modify the system files. The install procedure is also in a system file so it is tracked by the source code control system and protected from modification.
I don't really see much new here to protect against. What will be new is if this becomes a common problem. I don't see that happening in the immediate future. But if it does happen, I think it will have been built up in small steps, most of which are easy to argue as not being morally wrong.
For another example, not too long ago someone posted Perl code that did voting on PerlMonk nodes in batches. This was eventually removed by the author. Prior to that I wasn't aware of any complaints of malicious voting that I'd attribute to automated batch voting. The concept had been a running gag in the chatter box for a long time. Soon after that code was posted, I started to notice what eventually turned into a quite common complaint of malicious voting that did look like it was done in automated batches.
I can't even make an accusation that there is a cause and effect relationship involved in what I saw. I certainly have no evidence beyond coincidence of timing. It just worries me that some of the current problem may have been triggered, in part, by the appearance of that code. I certainly don't blame the author of that code. I'm also glad that it wasn't me because, being a guilty type, I'd probably feel terrible because of that doubt in my mind.
No, I don't think that refusing to post such code will prevent such things from happening. Yes, I do think that refusing to post such code can delay the inevitable and reduce the magnitude of it.
When I advocated removing the votebot code, several monks responded that we needed to solve the problem rather than hide it. We'll, the problem has been with us for quite a while now and a lot of talking and thinking has been done on it, and I don't think we've managed to do much as far as solutions go.
Solving problems takes time. I just like to help make the production of problems take more time rather than less.
-
tye
(but my friends call me "Tye")