Added by Eric Leblond over 1 year ago. Updated about 1 year ago.
Description
fileinfo contains the sha256 even if the file is incomplete. This leads to confusion as incorrect values are used.
sha1 and md5 are not exhibiting this behavior so fixing sha256 seems the way to go.
not sure, I vaguely remember someone showing some benefit for the current behavior...
If we stored a file, it will be stored with the partial hash as the file name. So it should be logging that file name then for sure. Not sure about the non-file-store case. @Jason Ish ?
Not sure myself.
What is incorrect about the values? Does fileinfo contain one sha256, but the file is stored on disk with another?
As these files are saved with file extraction, even when truncated, using the sha256 as the filename, we should still log the sha256 in the fileinfo record, so the fileinfo record can be associated with the file to disk.
I believe that is the intention, and why the sha256 is unconditionally logged. Code lacks a good comment around why we always log the sha256 though.
Truncated files can still be useful for further analysis was the argument I believe.
I think we can close this. Getting file even truncated for analysis is interesting.
Sorry for the noise.