Suricata

This creates an interesting problem...

If we only want this to happen in upgrades, it means adding an enabled field in the configuration file which turns this on. But the default would still be disabled, however we want this to be the default for new installs. This breaks the idea that a configuration file missing this field would have this enabled by default.

Could we add a "generated by" field to the suricata.yaml and use that to determine what some defaults should be?

Jason Ish wrote in #note-2:

Could we add a "generated by" field to the suricata.yaml and use that to determine what some defaults should be?

Should we have a ticket for this?

Juliana Fajardini Reichow wrote in #note-4:

Jason Ish wrote in #note-2:

Could we add a "generated by" field to the suricata.yaml and use that to determine what some defaults should be?

Should we have a ticket for this?

Yes

Jason Ish wrote in #note-2:

This creates an interesting problem...

If we only want this to happen in upgrades, it means adding an enabled field in the configuration file which turns this on. But the default would still be disabled, however we want this to be the default for new installs. This breaks the idea that a configuration file missing this field would have this enabled by default.

Could we add a "generated by" field to the suricata.yaml and use that to determine what some defaults should be?

Would it make sense to only make it a default yaml kind of default, but add a warning that the built-in default will change in 8?

Victor Julien wrote in #note-6:

Jason Ish wrote in #note-2:

This creates an interesting problem...

If we only want this to happen in upgrades, it means adding an enabled field in the configuration file which turns this on. But the default would still be disabled, however we want this to be the default for new installs. This breaks the idea that a configuration file missing this field would have this enabled by default.

Could we add a "generated by" field to the suricata.yaml and use that to determine what some defaults should be?

Would it make sense to only make it a default yaml kind of default, but add a warning that the built-in default will change in 8?

Does this mean that, for now:
i) we would add the master switch in the yaml file, with "enabled: true" by default
ii) search for the value in the yaml and, if it's enabled there, enable it, with the warning that this will be the built-in default from 8 onwards?
iii) if not present in the yaml file, we interpret as if "enabled: false"?

Victor Julien wrote in #note-5:

Juliana Fajardini Reichow wrote in #note-4:

Jason Ish wrote in #note-2:

Could we add a "generated by" field to the suricata.yaml and use that to determine what some defaults should be?

Should we have a ticket for this?

Yes

Not sure if I got it right, but: https://redmine.openinfosecfoundation.org/issues/5719

One option is to make this the new default in 7. To keep the old behaviour you have to add a new configuration field.

By warning in 7, we "smooth" the upgrade to 7. But still create a breaking change in 8.

If we make this the default in 7 and the old behavior requires adding the field, then that means that in the absence of the field, we have the new behavior enabled by default, right?

Is the break that you refer to here related to the fact that, in 8, if the field is not present, without any warnings the default is to drop everything?

Juliana Fajardini Reichow wrote in #note-10:

If we make this the default in 7 and the old behavior requires adding the field, then that means that in the absence of the field, we have the new behavior enabled by default, right?

Is the break that you refer to here related to the fact that, in 8, if the field is not present, without any warnings the default is to drop everything?

What I'm getting at is at some point in the future we make the change breaking one.. Or maybe better said a new default. Why delay til 8. Just break in 7. Document.