It looks like Scholar is not behaving the way we would expect when someone tries to upload an infected file.
Expected behavior
Scholar should alert the user via a flash message and drop the infected file instead of attaching it to the work.
Actual behavior
Scholar creates the work and attaches a file set like it would for a normal file. However, it looks like the file set may not contain a file. Trying to download the infected file gives a 404. So Scholar is not displaying a flash message and is creating a file set, but it does look like the actual infected file is being blocked from Fedora.
We used the typical EICAR test virus file to test this.
Descriptive summary
It looks like Scholar is not behaving the way we would expect when someone tries to upload an infected file.
Expected behavior
Scholar should alert the user via a flash message and drop the infected file instead of attaching it to the work.
Actual behavior
Scholar creates the work and attaches a file set like it would for a normal file. However, it looks like the file set may not contain a file. Trying to download the infected file gives a 404. So Scholar is not displaying a flash message and is creating a file set, but it does look like the actual infected file is being blocked from Fedora.
We used the typical EICAR test virus file to test this.
Commit that implemented virus scanning: https://github.com/uclibs/scholar_uc/commit/8161ecfdb278b91c93390ca74c38680f288f3496
It's possible that
Hydra::Works::VirusCheckerService
has had a new release since we implemented virus scanning and that external code broke something.