🚀 go-pugleaf

>From:    Eric_Florack.Wbst311@xerox.com
>
>>Actually, the strings are trivially "encrypted" to prevent the image
>>out on disk from triggering who-knows-how-many other scanners out
>>there.

>On /DISK/, yes. But consider the amount of scanners, including MAcAffee that
>look at RAM, as well. False trip city, as we have seen.

Sigh.  Look, I simply didn;t remove the strings from memory.  What's your
point?

>...[why should I bother to encrupt the strings except trivially?]...
>This misses the point altogether. My point was simply that without encryption
>of one sort or another, even in RAM,  another package wil false trip. If you
>think that people are going to depend on your package alone for protection,
>this might not cause a problem. But a realitry check, ( facilitated by a quick
>peek at the postings in here) will prove that doesn't happen.

No, I get the point: my income depends on it.  I had a bug.  It's fixed in
Version 1.5, released about ten minutes ago.  A reality check would show
that out of the thousands of people who run our code daily, about ten have
complained about the interaction due to a bug that is now fixed.

>My point in this case was the person doing the altering
>to routre around your code being the original author. Moreover, we
>have seen several varieties of a particular virus around, indicating
>more than one person altered one person's code. This is commonplace.
>(Can you say 'Stoned'? Sure. I knew you could.) Obviously, virus code
>is being passed around, by writers of such code, like a wine bottle at
>a garbage can fire. Getting the original code is therefore no problem.

No matter what string is used, and no matter what the encryption routine
for that string might be, it would be trivial to ascertain what that string
is -- and without having to break the encryption.  I know that your intentions
are most likely good, sir, but you really have not stopped to consider
all the issues before you post.  You may think you have the solution to a
non-problem, but your solution does nothing except add another area where
a bug can creep in without providing anything but a *potential* feel-good-
warm-fuzzy feeling.  It does nothing but provide me with extra work and
does not provide any benefit to the end user community.


>>>Encrypting the search strings in your code, therefore is always a good
>>>idea, as is cleaning up the mess your program makes in RAM. VIRx,
>>>apparently doesn't address these two points.

>>Wrong on both counts.  It is interesting, though, that about 20 beta
>>testers did not find that problem at all....

>First point: How on earth is cleaning up RAM you've allocated with
>your program before the program closes to be considered a BAD idea?
>Diito a string encryption?

Simply becasue somebody says that encrypting the strings is a good idea
does not make it a good idea.  And, except for a bug that occurred in
certain circumstances, the cleanup was typically done.


>As for your beta testers not finding the problem, I suggest to you
>that perhaps they missed a major problem.  WIthout being judgemental,
>here, finding this problem after beta was complete would seem to call
>into question the validity of certain of your test results.

Actually, it just showed that our beta testers did not run into that
problem (recall that the reports I mentioned above were limited in number).
This implies that they don't use one of our competitor's products. So what?
There are many people who opt not to use our competitor's products.  In
fact, I hope to make sure that hardly anyone uses any of my competitor's
products by providing better code than anybody else.

And, sometimes, a minor mistake is make and is blown way out of proportion.

Ross