A combination of packets can trigger an out of bound write of '0' byte
in the content-line analyzer.
This bug was found by Frank Meier.
Addresses BIT-1856.
Singular CR or LF characters in multipart body content are no longer
converted to a full CRLF (thus corrupting the file) and it also no
longer considers the CRLF before the multipart boundary as part of the
content.
Addresses BIT-1235.
The main change is that reassembly code (e.g. for TCP) now uses
int64/uint64 (signedness is situational) data types in place of int
types in order to support delivering data to analyzers that pass 2GB
thresholds. There's also changes in logic that accompany the change in
data types, e.g. to fix TCP sequence space arithmetic inconsistencies.
Another significant change is in the Analyzer API: the *Packet and
*Undelivered methods now use a uint64 in place of an int for the
relative sequence space offset parameter.
Replaced some with InternalWarning or InternalAnalyzerError, the later
being a new method which signals the analyzer to not process further
input. Some usages I just removed if they didn't make sense or clearly
couldn't happen. Also did some minor refactors of related code while
reviewing/exploring ways to get rid of InternalError usages.
Also, for TCP content file write failures there's a new event:
"contents_file_write_failure".