Closed makuhama closed 5 months ago
Hi. I have contributed a little to this project a while back. I created a fix for this back in 2019, PR #16 However, the pull request has been out for 2+ years and there is absolutely no activity or maintenance here from the owners, so don't count on this being fixed upstream any time soon.
I'll see if my company want to fork the repo and create a maintained version
We're using this client and are hitting this (very rare) issue for a specific file. Bugfix is indeed correct: don't rely on is.available(), but check read after reading.
@drogin : Did you create a fork + make the artifact available through maven central? (that's perhaps asking a bit too much :) )
a fork with the fix can be found at https://github.com/makuhama/clamav-java
a fork of clamav-rest referencing the fixed clamav-java can be found at https://github.com/makuhama/clamav-rest
sorry, no maven artifacts
InputStream.read(byte[] b) can return -1. This value is currently unconditionally used as 3rd parameter for OutputStream.write(byte[] b, int off, int len) - producing an IndexOutOfBoundsException. Actually the current situation creates a race condition. It starts with the response completely read from the InputStream. After a very short time another call to InputStream.read() is invoked. This call blocks, the FIN packet arrives, the TCP connection closes and the method returns with 0. Everything fine. With a very low-latency network the FIN packet arrives before the next call to InputStream.read(). In this scenario the method return -1. Bang! We have observed this issue in a Kubernetes pod with two containers communicating via localhost. One container running the ClamAV REST service (incl. the Clamd Java client) and the other running a clamd instance.