Suricata

The idea of a Suricata package manager has been discussed at times to make plugins easier to install. However, it should not be limited to just plugins. But also support Lua scripts (which are a form of plugins), and some thought about keeping it open enough to add other forms of packages in the future. In theory, even rulesets could be considered packages.

Some initial thoughts...

Installing a Package¶

Example: suricata-pkg install github.com/jasonish/redis-output

The tooling would know that this is a git repo, and fetch the code from the git repo and build it. Support would exist to look for a "Cargo.toml", "configure", or a "CMakeFile", and the tool would try its best. Alternatively, the repo contains a metadata file, "suricata.metadata" that provides additional build instructions.

The plugin would then be installed in the proper location for that Suricata installation.

One could also imagine suricata-pkg install crates.io/suricata-redis-output for a pure Rust plugin. cargo install, as far as I know, can't install or deal with pure library packages.

Issues:
- As the plugin is built locally, a toolchain is required
- Any libraries the plugin may depend on must be installed

Would have an associated uninstall command.

If the package was a Lua output script, they'd be copied into the correct location for those.

Enable a Package/Plugin¶

Example: suricata-pkg enable jasonish/redis-output

Essentially, activate/enable a plugin with the current plugin support, which would mean enabling it in the config file. But two directories, and moving/linking the file between them might be better. For example: plugins-available, plugins-enabled.

Would have an associated disable command.

If the package was Lua output scripts, etc. The enable/disable would do the right thing for that package type.

Binary Packages¶

The problem with distributing packages in source format is that the tools to build them are required when installing them. If installing Suricata from binary packages, it's typical that a toolchain may not exist on the system.

However, binary packages come with some additional challenged:

- Who will host them? We're pushing to plugins features that we cannot build in due to licensing of libraries, or patents. It doesn't really make sense that we can host these in a registry under our control? Maybe its OK? NPM has become a rather generic registry where binary only end-user tools are seeing distribution.

- Who will build them? The plugins we have in-tree right now either depend on proprietary libraries are libraries that are not ubiquitous.

- Versioning? Say the latest binary plugin links against libawesome.0.2.so, however the user still has libawesome.0.2.so

Registry¶

Do we need a registry? For example, Rust packages use a registry known as crates.io. Go(lang) packages don't, or at least didn't used to and used a name format like "github.com/foo/bar", where it would find a go.mod file.

A registry does help with discoverability, and doesn't necessarily need to host the actual plugins, but just metadata. For example, the Zeek package repo just has metadata linking to other repos: https://github.com/zeek/packages