Closed nwt closed 4 years ago
I think we're in good shape here from a functional perspective. I tested things out by manually downloading the macOS Zeek artifact from the most recent Actions run on this branch (https://github.com/brimsec/zeek/suites/1299072896/artifacts/20371620). In my local dev Brim environment, I removed the regular zdeps/zeek/
directory replaced it with the one from this artifact. Manually importing pcaps into Brim, I can see the Community ID field is populated as we'd expect:
I also made sure the other Zeek packages are still working as expected.
JA3:
HASSH:
geoip-conn:
I also did an npm run itest
to make sure that none of the Brim CI that deals with Zeek logs generated from pcaps were disturbed by the addition of the new Community ID field, and as I'd hoped, everything passed without complaint.
Test Suites: 9 passed, 9 total
Tests: 104 passed, 104 total
Snapshots: 54 passed, 54 total
Time: 222.266s, estimated 223s
Ran all test suites.
In conclusion, if you guys are ok with this at a code level, I'm game to see it merged so we can start delivering Community ID as a new field even in advance of the rest of Suricata support being ready. We've already had validation from our user community that it's helpful just to have the value from it even if they're manually cut & pasting the value out of Brim and into some other pane-of-glass where data is stored that has Community ID as a field.
The corelight/zeek-community-id package includes a Zeek plugin. Building and loading plugins doesn't work on Windows, so this change consists almost entirely of jiggery-pokery to address that, including a modified cmake submodule at https://github.com/brimsec/cmake.
Should close #36 and #37.