-
Notifications
You must be signed in to change notification settings - Fork 706
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Raise artificial 4G limit for MaxScanSize #986
Raise artificial 4G limit for MaxScanSize #986
Conversation
This limit is internally "long long", so >=64-bit even on 32-bit platforms. Also fixes a related issue where limits could have been set to negative values on 64-bit platforms where setting a "long long" (64-bit signed) can overflow if assigned from an "unsigned long" (64-bit unsigned). Resolves: Cisco-Talos#809
Some internal tests that expected specifying LogFileMaxSize to fail when using |
Thanks so much for the contribution @matthias-fratz-bsz |
Hey there! I'm still getting the following warning from LibClamAV:
I assumed this wouldn't be the case after this PR, have I misunderstood something? I'm running
I ran it in
which does not appear in |
@McPatate file-size is different from scan-size. file-size is still capped at ~2GB, and is the reason you're seeing that message. This PR only raised the limit for scan-size. |
@micahsnyder, just to clarify, does this mean that the maximum file size ClamAV can scan is 2GB - 1? In other words, ClamAV will only scan larger files if they are archives that, when uncompressed, exceed the 2GB limit and are thus subject to the MaxScanSize constraint. Is my understanding correct? If so, are there any plans to raise the limit here as well? |
@McPatate The maximum size for any file or extracted file is the max-filesize limit, so at most 2GB. The amount of data scanned while processing a given file is limited by the max scan-size. This includes:
Regarding the 2GB max file-size limit, see #344 |
Understood, thank you for taking the time to detail what is going on! |
This limit is internally "long long", so >=64-bit even on 32-bit platforms. Also fixes a related issue where limits could have been set to negative values on 64-bit platforms where setting a "long long" (64-bit signed) can overflow if assigned from an "unsigned long" (64-bit unsigned).
Resolves: #809