mirror of
https://github.com/projectsend/projectsend.git
synced 2026-09-24 04:16:20 +00:00
ignacionelson
c15c9c48f8
Run against the dev stack with real ClamAV and queue workers, and a code review looking for ways around the scanner. Quarantine now stays quarantined until somebody releases the file. A rescan only touches files people can download, and changes nothing when the scanner cannot answer or scanning is off. Before, an old infected file rescanned while clamd restarted went through the "allow" policy and became downloadable. The daily missing-files check leaves quarantined files alone, so a storage outage no longer brings one back as a fresh upload. A file longer than clamd's StreamMaxLength is "too large" again. clamd answers and hangs up; the next write raised a warning that became an exception before the answer was read, so the file was recorded as "scanner down" and retried past the unscannable policy. The production compose example gives clamd the settings it needs. On its own defaults an encrypted zip comes back clean. The Test button now sends a password-protected zip and fails when it is called clean, and says when an address answers but is not ClamAV. Saving the settings restarts the queue workers, which kept the old values in memory. New scan runs --all, as its name says, and is refused while scans are queued. A retry scheduled for later no longer counts as a scan in progress. Also: quarantine respects client scope for listing, release and notifications; a zip built before a file was quarantined is refused; public comments and version links skip unavailable files; a client no longer sees their own quarantined or missing upload; a file whose bytes return is scanned at once; clamd listens on IPv6 too, so its container health check passes.
38 lines
1.4 KiB
Plaintext
38 lines
1.4 KiB
Plaintext
# clamd settings ProjectSend depends on.
|
|
#
|
|
# The three Alert* options are not cosmetic. Without them clamd answers
|
|
# "OK" for a file it could not actually look inside — an encrypted archive,
|
|
# or one that hit a size limit — and ProjectSend would record a clean scan
|
|
# for a file nobody scanned. With them, those come back as
|
|
# Heuristics.Encrypted.* and Heuristics.Limits.Exceeded.*, which the client
|
|
# maps to "encrypted" and "too large" rather than to a threat, and this
|
|
# installation's own policy decides what happens to the file.
|
|
|
|
LogTime yes
|
|
Foreground yes
|
|
|
|
# Listen for the application on this network only. There is no
|
|
# authentication in this protocol; see the note in compose.yaml.
|
|
#
|
|
# No TCPAddr, so clamd listens on every address the container has. The
|
|
# image's health check asks "localhost", which resolves to ::1 first, and
|
|
# with TCPAddr 0.0.0.0 that check failed forever while clamd worked.
|
|
TCPSocket 3310
|
|
|
|
# The largest stream clamd will accept. ProjectSend refuses anything over
|
|
# its own "largest file to scan" setting before it gets here, and that
|
|
# setting must not exceed this number.
|
|
StreamMaxLength 512M
|
|
MaxFileSize 512M
|
|
MaxScanSize 1024M
|
|
|
|
# Archive limits, which is where zip bombs live. Reaching one is reported
|
|
# rather than passed, thanks to AlertExceedsMax below.
|
|
MaxRecursion 16
|
|
MaxFiles 10000
|
|
|
|
AlertExceedsMax yes
|
|
AlertEncrypted yes
|
|
AlertEncryptedArchive yes
|
|
AlertEncryptedDoc yes
|