Project

General

Profile

Actions

Feature #2341

closed

check versions of suricata and suricata-update

Added by Victor Julien almost 4 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Effort:
Difficulty:
Label:

Description

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

E.g. something like:

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

When 3.2 will be EOL later this month:
versions:
  suricata:
  - recommended: 4.0.3
  - 4.0: 4.0.3
  - 3.2: EOL
  - 3.1: EOL
  update:
  - 1.0: 1.0.0

suricata-update should probably get a 'check-versions' command:

# suricata-update check-versions
Info: index out of date, fetching
...
Warning: Suricata version 3.2.5 is End of life. Please upgrade to 4.0.3.

or
# suricata-update check-versions
Warning: Suricata version 4.0.1 is outdated. Please upgrade to 4.0.3.

ideally
# suricata-update check-versions
Info: Suricata version 4.0.3 is up to date.
Actions #1

Updated by Victor Julien almost 4 years ago

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

Actions #2

Updated by Shivani Bhardwaj over 2 years ago

  • Status changed from New to Assigned
  • Assignee changed from Jason Ish to Vagisha Gupta
  • Target version set to Soon
Actions #3

Updated by Vagisha Gupta about 2 years ago

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?

Actions #4

Updated by Jason Ish about 2 years ago

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.

Actions #5

Updated by Vagisha Gupta about 2 years ago

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

Actions #6

Updated by Victor Julien about 2 years ago

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.

Actions #7

Updated by Vagisha Gupta about 2 years ago

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]
Actions #8

Updated by Jason Ish about 2 years ago

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.

Actions #9

Updated by Shivani Bhardwaj about 2 years ago

  • Status changed from Assigned to Feedback
Actions #11

Updated by Jason Ish almost 2 years ago

  • Target version changed from Soon to 1.1.0
Actions #12

Updated by Jason Ish almost 2 years ago

  • Status changed from Feedback to Closed
Actions

Also available in: Atom PDF