greenber@utoday.UU.NET (Ross M. Greenberg) (02/02/90)
Y. Radai <RADAI1@HBUNOS.BITNET> writes about the checksum *installation* being too difficult for many people to use, and that, therefore, the presumption I make that "nobody has complained" (basically) might not be representative of the actual situation out there. Well. He could be right. I must admit that, if I were writing the program all over again, the installtion procedure would have been made a lot easier. In my wildest dreams, I never expected the program to have the success it has. However, in shareware, there always must be an incentive for people to register the program - else I don't make as much money as I could. Registered users of FLU_SHOT+ get an installation program that makes the job a little easier - still not as easy as falling off a log, but a little easier. Users of my commercial program get something that is as easy as falling off a log, though, and get a choice of different checksum routines. They can even pick more than one routine, and combine the resulting checksums/sigs into one signature. If people are expecting some real sophisticated checksumming stuff, though, they won;t find it in my stuff for the reasons I've outlined before. Perhaps I'll include some real tough checksumming in the commercial product, if there is enough interest. So, far, there doesn't appear to be any real interest, except (potentially) by *some* of the readers of this mailing list. >Sorry, but I don't understand why you have to get back to the "real" >checksum. Suppose we improve the security by making the checksums >different for each user. From the fact that some user's checksum has >changed relative to *whatever* it was when that user set up his >checksum base, we'd know precisely the same thing that you know by >comparing with the "real" checksum, namely that his file had been >altered (which *may* indicate infection). So what do you gain by use >of the "real" checksum? I get people calling me up with problems on them checksumming already infected files. In most of these cases, they were not aware of the problem. By knowing the checksums of some popular programs (not just the system files), I can ask them to forward me a list of their checksummed files, ask a simple question or two and then figure out, potentially, what file is infected. Remember that I'm supporting (as of date) just over 20K users. That causes me to have to make some compromises, and more's the pity: each update has to take longer because it affects more people, more users. There are estimates that only 1% of the users of shareware ever register. If this is the case, then I have a responsibility to take things *very* slowly with any change I make. That's not to say that I won't consider making such a change, just that there is a heckuva lot more that goes into making a change that increases the security of the product by .00001% (or whatever) but that affects 100% of the users, registered or unregistered. I have a wish list of changes to make to the shareware version and to the commercial version. For obvious economic reasons, the commercial version gets all the enhancements first. For certain legal reasons, some changes can never make it into the shareware version. Just to reiterate: I never expected FLU_SHOT+ to have the popularity that it does, nor did I realize the restrictions such popularity places on the author when it comes to updating the code. Ross