Stephen Gran wrote:
This one time, at band camp, Antonio Fiol said:
I am using clamd in STREAM mode in every case.
I have found a way of fooling the scanner to give a false negative:
If the user sends a BIG file (bigger than the limit) with a virus near the end (outside the limit), it will get cut, and the virus will not be found.
IMO, the scanner should detect this as an exceptional situation, and react by saying: stream: ERROR:Size-limit-exceeded FOUND
Or any other informative string.
Upstream's response is that you should set your MTA limits for message
size to be the same as your settings for stream size, so that you can
just reject over size messages outright. Apparently that means they
don't want to accept your patch :(
Just a minute! I don't have any MTA! Our use of the clamav antivirus is related to a completely different app. There is no e-mail involved.
The logic is that the Archive related options and ArchiveBlockMax are
to prevent against archive bombs. But it is trivially easy to control
the size of the data being fed to clamav, unlike knowing in advance the
content that will go through.
I agree on that. But I disagree on the fact that the antivirus administrator (and thus, the person responsible for his system saying: "No virus found using pattern file XYZ") may be, and will most likely be, in our case, not in charge for the configuration of the application, which, for now, does not even control the size of the data, as it has no specific requirement on data size.
Of course the app could be modified to handle data size. But IMHO, if the size limit is something related to the antivirus system, the limit should be (only) configured on the antivirus system.
To upstream: I beg you reconsider your position, having read the above.
And thank you all anyway for your attention.
smime.p7s
Description: S/MIME Cryptographic Signature
