-
Notifications
You must be signed in to change notification settings - Fork 1
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
Files not scanned on update or change #147
Comments
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 |
Done with #160 in next release 30.1.3 |
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 #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).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
The text was updated successfully, but these errors were encountered: