Zeek 3.2 Release Candidate Available—and Zeek 3.1.5 and Zeek 3.0.8 as well

We are very happy to make a first release candidate of Zeek 3.2 available today. Barring any unforeseen issues, the final 3.2 release should be out in about two weeks from now. We highlight some updates in 3.2 below. Please see NEWS for full release notes, and CHANGES for the exhaustive list of changes. We don’t recommend release candidates for production usage, but we encourage you to give it a try and report any rough edges you may encounter. We’ll do our our best to address any issues that we learn about before the final release.

We’re also releasing Zeek 3.1.5 and Zeek 3.0.8 today as maintenance updates for the current stable releases; they are likewise available on the Downloads page. These updates include a couple of security fixes, and we recommend upgrading. Please see the change log for the 3.1.x and 3.0.x series, respectively, for what’s changed. 

Some highlights in Zeek 3.2 include:

• Zeek now supports synchronizing tables/sets across clusters through a backing Broker data store. The same feature also facilitates persistent storage of data in tables/sets across Zeek restarts. In some sense, this is a replacement for the previous &synchronized and &persistent keywords that older Zeek versions offered. See the documentation for more information. Please note that this feature remains experimental and may further change in its specifics. 
• Zeek now caches X.509b certificates once observed. If a certificate is encountered again, it will then not have to re-parse it, which substantially improves performance with commonly seen certificates.
• Events and hooks are now allowed to have multiple, alternate prototype declarations. This allows for extending event/hook parameters in a way that won’t break existing handlers. See the documentation for more information. 
• Zeek now supports the Remote Desktop Protocol UDP Transport Extension (RDPEUDP, versions 1 and 2).

Internally, the Zeek 3.2 release comes with lots of modernization across the C++ code base. In particular, the code is now using smart pointers instead of raw pointers at many locations; and a large number of classes, functions, and types have moved from the global namespace into new zeek::* and zeek::detail::* namespaces. While this transition is not complete yet, our goal is to come to to a stable API for C++ plugins. Going forward, we will handle changes to anything the inside zeek namespace in accordance with our deprecation policy. In contrast, while the content of zeek::detail will remains accessible to plugins as well, we won’t be providing guarantees about API stability for that part.

By its nature, the modernization of the code base is pretty invasive and may require existing plugins to update their code. For many of the changes, we were able to retain backwards-compatibility, so that plugins will continue to build while reporting deprecation warnings that point to the places that will need adjustments. In some cases, however, we had to accept that existing code will stop compiling because C++ didn’t allow for a backwards-compatible migration path. Please see CHANGES for an extensive list of API updates and now deprecated functionality. If you run into problems updating your code, feel free to reach out on Slack or mailing list, and we’ll be happy to help.