[I had posted this on Slack in #development originally, copying here
for visibility]
We now have the nice list of platforms that Zeek currently supports
at: https://github.com/zeek/zeek/wiki/Zeek-Operating-System-Support-Matrix.
We however don’t have a policy yet what platform we generally aim to
support going forward. Dominik and I discussed this further the other
day and came up with a proposal:
1. For each distribution, we decide on a dedicated policy which
versions we want to support at any point. A general rule of thumb
would be “the two most recent stable releases still within their
support window”. But we’d actually look at each distribution and
see what policy makes sense, including any additional dependencies
we will rely on (like devtools on CentOS). And we do
mini-request-for-comments to get feedback from users if we’re
making a reasonable choice.
2. We update CI to test those versions, and *only* those versions.
3. We then rely on CI to decide if changes are ok: If, e.g.,
somebody wants to use a new C++ feature, that’s ok as long as CI
passes. If it breaks CI, it won’t go in.
The advantage of this is that we won’t rely on having to specify
specific compiler versions, which isn’t well-defined (because things
also depend on libstdc++ version, system libs, etc.), but instead on
whether people can actually compile Zeek on the platforms they are
using.
A disadvantage is that we’ll need to spend the time to ensure our CI
setup keeps matching the policies, and gets updated as distribution
updates come out.
Thoughts?
Dominik added:
> I think you’ve summarized it nicely! I’d only add that we’ll have to
> keep our CI up-to-date regardless. Jon is already doing a great job
> staying on top of things and adding EOL dates to dockerfiles as
> comments to make it obvious when things can get dropped from Cirrus.
> Also, I’m obviously I’m in favor of this proposal. :wink:
> The “everything that passes CI is fair game” approach not only makes
> sure we naturally catch up to new C++ features eventually (which is
> the main motivation), but we can also steadily modernize our CMake
> scaffold, Python scripts, and so on.
--
Robin Sommer * Corelight, Inc. * robin(a)corelight.com * www.corelight.com
Something I'd like to figure out is how to document new notice types in the
package documentation.
If I add a new notice type, e.g.
> redef enum Notice::Type += {
> ## IPv6 Router Advertisement packet seen with the Recursive
> ## DNS Server Option that had length which could cause a
> ## buffer overflow and can lead to code execution.
> Bad_Neighbor_RCE_Attack_Detected,
> ## IPv6 Router Advertisement packet seen with the DNS Search
> ## List Option that had a length which will cause a buffer
> ## overflow and can lead to a Denial of Service.
> Bad_Neighbor_DoS_Attack_Detected,
> };
All that Zeekygen generates is something which tells me that Notice::Type
was redef-ed, but the comments on the specific types are lost:
> Summary
> ~~~~~~~
> Redefinitions
> #############
> ============================================ =
> :zeek:type:`Notice::Type`: :zeek:type:`enum`
> ============================================ =
(I'm also not sure why there's a space before the last = on those lines).
Another example is visible here:
https://raw.githubusercontent.com/zeek/zeek-docs/master/scripts/policy/prot…
If we look at the documentation for Notice::Type, all the new types are
documented there:
https://raw.githubusercontent.com/zeek/zeek-docs/master/scripts/base/framew…
However this doesn't work when moving detections to packages.
It seems like this is missing from Zeekygen, but I'm not sure of the right
fix. Most enums don't have comments for the various values. Do we look for
comments for all enum values, and provide them if found? Or do we
special-case Notice::Type?
--Vlad
