manager: Spicy specific builtin-plugin discover

[awelzel]

This is my take on zeek/zeek#2243 for the time being. I've tried to think of other open-source plugins that are a major dependency for other packages and subject to be built-in Zeek base and no obvious ones came to mind.

Maybe CommunityID or JA3 packages, but the former was discussed and not further considered as builtin/native functionality.

This obviously doesn't help custom Zeek builds that build in other plugins - that would possibly be a motivation for a more generic approach as outlined in the commentary, but my interpretation currently is that this revolves around spicy-plugin particularly.

[awelzel]

And seems half of the change would anyway be required for a more generic approach that has Zeek side support.

[ckreibich]

Thanks Arne. I'm against the special-casing, but only to a point. :-) My take on the whole thing is this:

Zeek's builtin-plugin feature is cool but our implementation is partial, because we failed to recognize the potential of collisions between Zeek with such plugins and the corresponding packages. The user experience when somebody is unaware or forgets is pretty horrible. We do have power users who build their own Zeek binary packages, and I think it's very possible that they like this feature because it saves them separate plugin compilation/installation.

Doing this generically is certainly more work but it doesn't strike me as crazy. There are a couple of developments underway that relate. We have long wanted a zeek-config --build-descriptor (touched in zeek/zeek#1405) or some such, that outputs details about a specific Zeek build — the state of the submodules, compiler settings, etc — a superset of what the individual zeek-config flags give you, perhaps in JSON to be machine-processable. It doesn't seem too hard to include a Zeek build's plugin info there (it's all in cmake), expand cmake to understand whether a builtin plugin is a Zeek package and grab its metadata. zkg can then unify that info with its own manifest..zkg, and proceed as usual.

Right now we should wait for Dominik's plugin cmake overhaul to land before looking more closely at this. I suggest we leave this PR open in the meantime until we can explore further.

[awelzel]

Doing this generically is certainly more work but it doesn't strike me as crazy.

It's not. It should be pretty clear which part to replace from this changes (zeek -N |grep Spicy) with the generic version (and most of the rest seems somehow needed).

I suggest we leave this PR open in the meantime until we can explore further.

Fine for me. I'm fully aware this was a stop-gap, but also a step towards the generic version.

[awelzel]

Closing. Replaced with #157