It was pointed out by a contributor that our workflow mentioned
rewrite-branch as the preferred way, while in fact our policy is to add
said changes to a different commit. Updating documentation to prevent
other situations like that.
Although we prefer that formatting changes (e.g. the ones made by
running clang) go in a different commit, our script error message was
still suggesting `rewrite-branch` as an option. Removed that and added
that the changes made by the script should go into a separate commit.
This flag is no longer needed as a parser can now create a transaction
as unidirectional.
Setting this flag also doesn't make sense on parsers that may have
request/reply and some unidirectional messaging.
Use a fixed type of max_pending_packets instead of intmax_t which can
differ based on the platform/standard library.
Should also prevent lints about possible arithmetic overflow.
Problem:
If we receive a long line w/o LF, we cap it to 4k bytes and wait until a
line with LF comes in order to consider the previous line complete. Any
data post the 4k bytes is discarded. Currently, if a line with LF comes
in after a long line, we reset all the parameters used for processing it
like the line.len and line.delim_len but we still make the call to
SMTPProcessRequest fn without even the need to process anything. Since
such a line (with len and delim_len set to 0) should not reach mime
decoder, a debug assertion triggers there in this case.
Fix:
Make sure to return early as the line has to be skipped and not
processed at all.
Bug 6019
When reading a loopback interface, packets are received twice: Once as
outgoing packets and once as incoming packets.
Libpcap ignores outgoing packets. With current versions of Suricata, sniffing
a single http://localhost:80 request over lo using the af-packet source
minimally shows two syn packets, two synacks and twice as many packets in
the stats entries than you'd expect when running tcpdump or Wireshark.