Description

I recognized that files once scanned are not re-scanned on update or change by (remote) clients.
This open a door to distribute corrupted files marked as clean and is not the expected behavior of end users.

Reproduce

1. upload a clean file with nextcloud client to the server
2. wait until initial scan happen and file is marked with the clean tag
3. upload a file with eicar signature overwriting the file created before (e.g. from https://www.eicar.org/download/eicar_com-zip)
4. wait a couple of hours (the updated file is not scanned anymore)

This can easily misused by replace files marked as clean before to distribute vulnerable files afterwards.

Expected behavior / Proposal

• GData VaaS should re-scan any files received an activity/change since initial scan

It might be related to #144 and can be addressed by an own managed database table keeping track of files processed as mentioned in #144 (comment).

My idea would be to store the date scanned or checksum of an file id within that GData_VaaS_table (etag might be also a candidate).

• If a fileid in oc_filecache does not appear in GData_VaaS_table: scan it
• If a fileid in oc_filecache appear in GData_VaaS_table has the same (mtime and checksum and etag): skip scan
• If a fileid in oc_filecache appear in GData_VaaS_table but has different (mtime or checksum or etag): scan it

The tags on the file are just informative to the end user to easily identify potential dangerously files. But should not be the source of truth about what to scan.

Versions

• Nextcloud Hub 8 [29.0.7]
• Gdatavaas [29.4.3]