Add the new test TOOL-5130 (Check for active Suricata daemon) to the tests
database and update the changelog accordingly.
Signed-off-by: Timo Sigurdsson <public_timo.s@silentcreek.de>
Commit 94e0a4e added a test for the Suricata binary, but the result appears to
be used nowhere. Add a proper test for an active Suricata daemon in the
IDS/IPS tooling section.
Signed-off-by: Timo Sigurdsson <public_timo.s@silentcreek.de>
Improve handling of kenrel files
/boot/vmlinuz-linux-lts
/boot/vmlinuz-linux
/boot/vmlinuz-lts
by updateing RegEx and adding elif
this corrects issue where version is identified
as 'linux' or 'lts' causing false report that a
reboot is needed
Apple doesn’t disclose when it stops providing security updates for
macOS versions. There’s no consensus on when the exact EOL date is.
Lacking that information, I applied the following ruleset, which is
driven by what people have observed, and seems pragmatic enough:
- From Mac OS X 10.0 through 10.4, a version 10.N would be considered
EOL on the day the first patch-level update 10.(N+2).1 for its
N+2 successor was released.
- Starting with 10.5, Apple began to support three versions at the same
time. For 10.5 itself, the EOL date is difficult to pin down so I
went with 2011-06-23, the date given by the English-language
Wikipedia.
- From 10.6 through 10.11, a version 10.N would be considered EOL on
the day the first patch-level update 10.(N+3).1 for its N+3 successor
was released.
- Starting with macOS Sierra (10.12), Lynis counts the patch level.
Any version 10.N.P can be considered EOL on the day 10.N.(P+1)
is released. If that hasn’t happened, the EOL date is the day
10.(N+3).1 is released. If neither has been released, 10.N.P has
no EOL date.