Consider installed zeek and zkg versions when finding best version tag

[ckreibich]

When a package has version tags, installation of that package without requesting a specific version or branch causes zkg to pick the numerically greatest version tag (based on semver ordering). That's definitely reasonable, but we currently don't deviate from that version even if it's incompatible with the installed Zeek or zkg version.

Over time, it's pretty likely that newer version tags are compatible only with newer Zeek versions. If a package doesn't make those dependencies explicit, there's not a whole lot we can do, but when it does, I'm thinking it would be reasonable to step backward through the version history to find one that's compatible with what's locally available.

Consider Community ID: its latest version (3.2.0) works with any Zeek >= 3.2, and it has older tags that work with older Zeeks. If I have a recent Zeek, all is well, but with an older Zeek this happens:

$ zkg install zeek-community-id
error: failed to resolve dependencies: unsatisfiable dependency: "zeek" (3.1.5) is installed, but "zeek/corelight/zeek-community-id" requires >=3.2.0

To fix this, you have to know which version tag to pick. It's documented in the README, but the user needs to figure it out. I put together a prototype that walks back through the tags, here ... with it I get:

$ zkg install zeek-community-id
The following packages will be INSTALLED:
  zeek/corelight/zeek-community-id (3.1.0)

Proceed? [Y/n]
Running unit tests for "zeek/corelight/zeek-community-id"
Installing "zeek/corelight/zeek-community-id"..
Installed "zeek/corelight/zeek-community-id" (3.1.0)
Loaded "zeek/corelight/zeek-community-id"

It first considered the latest tag, 3.2.0, which fails the Zeek dependency, and then moved on to 3.1.0, which is marked compatible with Zeek 3.1.5, currently installed.

I'm definitely not sure this is the right way to do it since the code has a few spots where it picks the greatest version number and the dependency code is a bit tricky. I was mainly curious to see if other hiccups would come up, but it seems manageable.

Thoughts?

[0xxon]

I feel like this is generally a good idea, with one bit but.

I think we should make it very obvious (much more obvious than in the current output) that the version that is being installed is not the up-to-date version.

We also should consider what this means from a security point of view. Consider someone writing a protocol analyzer that works for Zeek version A. Then a new version of Zeek comes out - and the analyzer gets updated. Then a security issue gets found and fixed.

If you install the package with an old version of Zeek - you, in this case, will get a package installation with a known vulnerability, that will probably never get updated.

I know that this might seem a bit far fetched - but I actually see a pretty good chance that something along these lines will eventually happen.

[ckreibich]

Yeah Johanna, agree to all.

[jsiwek]

Thanks, seems like a neat idea to me, too, and I'd also try to make what's happening clearer to user. An alternate way to do that may even be to avoid any change to preferred-version/dependency-analysis code: instead the logic on the zkg side can attempt to find that out and suggest it? Possible output:

$ zkg install zeek-community-id
error: failed to resolve dependencies: unsatisfiable dependency: "zeek" (3.1.5) is installed, but "zeek/corelight/zeek-community-id" requires >=3.2.0
    3.1.0 is the last version of "zeek/corelight/zeek-community-id" compatible with "zeek" 3.1.5,
    but it is not the latest/requested package version (3.2.0).  If you're sure about installing an
    older version, use:

        zkg install --version=3.1.0 zeek-community-id

Hard to install old/outdated packages or get them by mashing "yes" without conscious thought that way. Not that I know what level of convenience/safety tradeoff is most efficient, but think that still addresses problems presented:

• Effort required by user to discover what the last-compatible version actually is
• Risks associated with automatically picking old/outdated package versions
• Trickiness of adding more complexity to preferred-version/dependency-analysis code and convolution of associated documentation.

[ckreibich]

Nice, that would work for me! It's an extra step for the user, but it's reasonable for us to be concerned, and I also like that this is a bit of a nudge to upgrade Zeek (or zkg).

On the implementation side it would be nice if the dependency validation code indicated explicitly that failure is due to Zeek/zkg versions ... I believe it currently would tell us only by parsing the error message. But that won't be hard to add — for example, we could return the offending node(s) in some form.

An aside on adding more functionality to the toplevel zkg script: we may want to consider a refactoring pass that pushes a lot of the command functionality into the zeekpkg module. Everything we add to zkg remains unavailable to module users, and there's quite a bit of code at this point.

[ckreibich]

I just realized there's also zkg upgrade, which may likewise pull packages to the latest version tags. To mirror the install behavior zkg could indicate via prompting when those versions would be incompatible with the local Zeek/zkg, say which versions would be okay, and leave it to the user to abort at that point. This leaves it to the user to figure out what to do, but would avoid breaking the installation.

[rsmmr]

Doing that error message + "here's what to do if you're sure" sounds good to me too.

The one other idea I'd have it leaving it to the package author: we could enable them to declare in the meta data of the most recent version what older versions to fall back to in which case (i.e., some form of dependency spec saying Zeek 3.2 -> v3.2.0, Zeek 3.1 -> v3.1.5, Zeek 3.0 -> error / not supported, etc.).