In worktree scenarios, .git is a file. Assuming its a directory causes
the release date to check the ChangeLog instead of the last commit,
while not a big issue, can be confusing.
When outputting a float, check if its infinity, or not a number and
output a null instead.
Using a null was chosen as this is what serde_yaml, Firefox, Chrome,
Node, etc. do.
Ticket: #6921
Function prototype has changed in a recent release. Rather than dealing
with detecting that, fall back to our regular pattern of using
pcre2_substring_copy_bynumber().
Bug: #6918.
While the checkout job appears to do this, it is done with a different
version of git which seems to be the cause for it not having an effect
when doing manual git operations from within a job.
Also removes duplicate checkout statements in Windows builds.
Sphinx embeds a date in the generated man pages, and to provide
reproducible builds this date needs to be provided to Sphinx,
otherwise it will use the current date.
If building from Git, extract the date from the most recent commit. In
a release, this commit would be the commit that sets the version so is
accurate.
If .git does not exist, use the most recent data found in the
ChangeLog.
The ChangeLog is not used when building from git, as the main/master
branch may not have recent enough timestamps.
This should provide a consistent date when re-building the
distribution from the same non-git archive, or from the same git
commit.
Ticket: #6911
By default, when Sphinx generates the man pages, the current date will
be embedded in them. This can be set to a specific date with the
"today" variable. Typically the date embedded in manpages in the
release date.
To achieve this, attempt to use the environment variable, RELEASE_DATE
to set the "today" variable, reverting back to the empty string if not
set. It is up to our build system to properly set this date.
Ticket: #6911
So far, if a port was found to be single which was earlier a part of the
range, port + 1 was added to the list to honor the range that it was a
part of. But, this is incorrect in case the port is 65535 or if the port
was found to be of range when it was earlier a single port.
Bug 6896
Expose LoadYamlConfig as SCLoadYamlConfig and remove it from
SuricataInit. This is required to allow the library user the ability
customize the loading of the configuration, for example doing some
programmatic configuration then loading a configuration file.
A configuration sequence node needs to have name, which is just its
index in the sequence.
Discovered by calling ConfDump() after Suricata was fully initialized.
Move the contents of SuricataMain into the `main()` function found in
main.c. This forces the Suricata application to bootstrap and run
Suricata through the same interfaces as a library user might do.
Required exposing StartInternalRunMode as SCStartInternalRunmode. Its
arguable whether those "actions" belong in the library or just the
application, but I think that is separation we can look at later.
For now the lib example and Suricata's own main are the same, however
the example will probably extend more into programmatically
configuring Suricata or dynamically registering a runmode, which
doesn't really belong the main Suricata application.
Expose the functions FinalizeRunMode and ParseCommandLine to library
users, renaming with the `SC` prefix in the process.
This involves moving "application" level details from SuricataInit
into SuricataMain, as parsing command line options should be opt-in
for a library user.
We want to be able to call ParseCommandLine from library users, but
currently library users don't have access to the `suricata` instance
type. Since this var is used other places as a global, use the global
one in ParseCommandLine as well.
Not ideal, but isolating SCInstance to a non-global will be another
challenge on its own.
Move WindowsInitService from SuricataInit() to SuricataMain(), as
initializing Suricata as a service is very specific to the application
and not something you'd want to happen in a library, and SuricataInit
is more common initialization for application and library usage.
Expose SuricataMainLoop and GlobalsDestroy so that SuricataMain can be
replicated by a library user of Suricata.
These removes the `suricata` instance as a function argument to some
of these functions, as the way we use it now, it serves no
purpose. However, it is a reminder that it should probably be
refactored to not be a global, as at some point it might be desirable
for to have multiple instances active without data sharing.
If a single port happens before a range port, the port groups created
were incorrect. Fix it to use smarter range check.
For example, given,
80:80 - SGH1
100:120 - SGH2
Range created should be
80:80 - SGH1
100:120 - SGH2
Bug 6881
error: unnecessary use of `to_vec`
--> src/smb/smb.rs:1048:62
|
1048 | let (name, is_dcerpc) = match self.guid2name_map.get(&guid.to_vec()) {
| ^^^^^^^^^^^^^^ help: replace it with: `guid`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unnecessary_to_owned
= note: `#[deny(clippy::unnecessary_to_owned)]` implied by `#[deny(warnings)]`
And also other uses of to_vec() on already Vec
Ticket: 6883
error: field `0` is never read
--> src/asn1/mod.rs:36:14
|
36 | BerError(Err<der_parser::error::BerError>),
| -------- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| |
| field in this variant
|
Issue: 6861
Without this commit, disabling rule profiling via suricatasc's command
'ruleset-profile-stop' may crash because profiling_rules_entered becomes
negative.
This can happen because
- There can be multiple rules evaluated for a single packet
- Each rule is profiled individually.
- Starting profiling is gated by a configuration setting and rule
profiling being active
- Ending profiling is gated by the same configuration setting and
whether the packet was marked as profiling.
The crash can occur when a rule is being profiled and rule profiling
is then disabled after one at least one rule was profiled for the packet
(which marks the packet as being profiled).
In this scenario, the value of profiling_rules_entered was
not incremented so the BUG_ON in the end profiling macro trips
because it is 0.
The changes to fix the problem are:
- In the profiling end macro, gate the actions taken there by the same
configuration setting and use the profiling_rues_entered (instead of
the per-packet profiling flag). Since the start and end macros are
tightly coupled, this will permit profiling to "finish" if started.
- Modify SCProfileRuleStart to only check the sampling values if the
packet hasn't been marked for profiling already. This change makes all
rules for a packet (once selected) to be profiled (without this change
sampling is applied to each *rule* that applies to the packet.
Ticket: 6799
When we find an overlong banner, we get into the state just
waiting for end of line, and we just want to skip the bytes
until then.
Returning AppLayerResult::incomplete made TCP engine retain
the bytes and grow the buffer that we parsed again and again...
Ticket: 6578
When a protocol such as SSH sets no_inspection, we still have to
flush the current streams and packets that contain clear-text
for detection.
Ticket: #6305
When running FlowWorkerStreamTCPUpdate, one of the dequeued packet
may set the flow action to drop, without updating the not-pseudo
packet action, as is done usually with a previous call to
FlowHandlePacketUpdate
Victor Julien
Jason Ish
dependabot[bot]
Philippe Antoine
Shivani Bhardwaj
Angelo Mirabella
Jeff Lucovsky