Open kriegerse opened 1 month ago
Hi again, thanks for reporting!
FYI, we currently have kind of a "sick wave" with influenza and such being passed around. We therefore haven't had much time to look into this yet, but we will get to it when we can. We appreciate the reports!
We cannot reproduce this with the Web UI.
Which Nextcloud client are you using?
Sorry for the delayed response, was on a business trip past week.
My scenario is not about the file upload within the web UI what is working well but the remote client(s).
Specifically I running a Linux Box (Linux Mint 22 aka Ubuntu 24.04 LTS) with the nextcloud desktop client.
I assume other remote clients and OS behave similar.
From my point of view rely on tags here is not a good idea as they are not reset on file update (for good reasons).
Linked to #157
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
clean
tagThis can easily misused by replace files marked as clean before to distribute vulnerable files afterwards.
Expected behavior / Proposal
It might be related to https://github.com/GDATASoftwareAG/nextcloud-gdata-antivirus/issues/144 and can be addressed by an own managed database table keeping track of files processed as mentioned in https://github.com/GDATASoftwareAG/nextcloud-gdata-antivirus/issues/144#issuecomment-2402283944.
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).oc_filecache
does not appear inGData_VaaS_table
: scan itoc_filecache
appear inGData_VaaS_table
has the same (mtime and checksum and etag): skip scanoc_filecache
appear inGData_VaaS_table
but has different (mtime or checksum or etag): scan itThe 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