Zeek 3.2 Released

(This is an updated version of the previous RC announcement.)

We are very happy to make Zeek 3.2 available today. Some highlights of the new release 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).

Please see NEWS for full release notes, and CHANGES for the exhaustive list of changes.

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.