Suricata » Suricata-Update

Wonder if this should automatically run say once a week or month too as part of the regular 'update' operation.

Victor Julien wrote:

The version info for both suricata and suricata-update could probably made part of the index.

E.g. something like:
[...]
When 3.2 will be EOL later this month:
[...]

For this issue the versions info should be stored in Suricata Intel Index which is currently a list of available rule sources. The first step here should be to update the Suricata Intel Index by adding versions. Am I right?

Vagisha Gupta wrote:

For this issue the versions info should be stored in Suricata Intel Index which is currently a list of available rule sources. The first step here should be to update the Suricata Intel Index by adding versions. Am I right?

Correct. For development purposes you can use the environment variable SOURCE_INDEX_URL to point to your checkout of https://github.com/OISF/suricata-intel-index. You will have to do a pull request to this repo as well to add the new items to the index.

Is the versions info here correct or is there any change in it?

versions:
  suricata:
  - recommended: 4.0.3
  - 4.0: 4.0.3
  - 3.2: EOL
  - 3.1: EOL
  update:
  - 1.0: 1.0.0

No these are outdated. The current recommended release is 4.1.4. All branches except 4.1.x are EOL.

We do need a way to also track the development branch I think, or at least not generate a warning for that.

I've tried to come up with following structure to be included in index. Does this seem fine to you? Please correct me if this is not the right way to add versions or any version info is wrong.

versions:

  suricata:

    Development: 5.0.0-beta1
    Recommended: 4.1.4
    Stable: [4.1.4, 4.1.3, 4.1.2, 4.1.1, 4.1]
    EOL: [4.0, 3.2, 3.1, 3.0, 2.1, 2.0, 1.4, 1.3, 1.2, 1.1, 1.0]

  update:

    Recommended: 1.1.0dev0
    Stable: [1.0, 1.1]

I wonder if it would help to think about the messaging we want to give to the user?

Take the current situation where we have only one supported branch, 4.1, with the latest being 4.1.4 (which will be recommended).

User is running 4.1.1, but less than 4.1.4.

Say we have YAML like (adapted from Victor's to not use lists):

versions:
  suricata:
    recommended: "4.1.4" 
    "4.1": "4.1.4" 

We can look at versions["suricata"]["4.1"]. If it is defined, and the value (here: 4.1.4) differs from the current version, we display:

Warning: Suricata version 4.1.1 is outdated. Please upgrade to 4.1.4.

If the user was running "4.0.5", the lookup in the versions would have been undefined. We can use this as an EOL, or we could add `"4.0": EOL` to the YAML. Either way the output would be something like:

Warning: Suricata version 4.0.5 is EOL. Please upgrade to $RECOMMENDED.

When we release 5.0, which may also happen close to a 4.1.5 release, the index will be updated to be like:

versions:
  suricata:
    recommended: "5.0.0" 
    "5.0": "5.0.0" 
    "4.1": "4.1.5" 

Here the 4.1 user will be notified that 4.1.5 is available. We might want to add logic to display something like:

Warning: Suricata version 4.1.1 is outdated. Please upgrade to 4.1.4 or $RECOMMENDED_VERSION.

I'm not positive we can get this kind of logic with your proposed YAML. I also don't think we need to exhaustively list every version in the YAML.

Regarding development versions, where "dev" is in the version, it might be easiest to just skip the version check for now in that case. I think we could still do something useful here, but focus on the non-dev versions first. Additionally if the Suricata version is greater than the recommended version, then don't output anything as well.

PR: https://github.com/OISF/suricata-update/pull/182