Suricata

Also tcp-stream

Did not find a place to add to sigmatch_table.

AFAICS this is true for all of those defined in detect-engine-proto.c so is it still the better approach to go for hardcoding them?

https://github.com/OISF/suricata/pull/3902

Although we can also go for the suggestion from #1872 what do you prefer?

One solution may be to add a test that will do a diff between the output of `suricata --list-keyword` and `grep strcasecmp src/detect-engine-proto.c | cut -d'"' -f2`

I agree.

Should we add another line at the "Supported Keywords" output to make sure folks know that there are more specific keywords available as well?

Just want to avoid people missing keywords cause they missed they are listed in another section.

You can experiment with what that could look like. In general having all the options nicely grouped in suricata -h and the man page would go a long way too I think.

I played around with it and also saw that I forgot to add the output for the options =all and =csv. I don't think it should be solved different as it makes sense for the case in #1872 where we have some protos that aren't a keyword while we have only keywords here. So as a user I would expect to see really all keywords. This list might grow huge and so far we don't have a nice sorting or logical split between the keyword list. So I have some ideas:

1. Just add the missing keywords hardcoded to have those in the same output. This is easy but a bit ugly due to the hardcoding
1.1. I don't see how it get be done like all the other keywords without a bigger rewrite of the code of this part. I don't think we will add many in the future but the more generic way looks much nicer. So maybe a rewrite might be worth it.

2. Rewrite the whole "list-keywords" part to restructure the ouput to make it easier to read/parse instead of just a plain list. The most difficult part is to define how it should look like, how we want to sort and group and make it clear how it would behave for new keywords.

3. You mentioned the man page as well. Wouldn't it be enough to have the keywords listed and explained in the documentation and also in the manpage so you have it local? This also means more effort.
3.1. Currently we have 192 lines of output in --list-keywords, with =all even 694 lines. IMHO that's not perfect for outputs.
3.2. We can still keep the command line options and link to the docs and/or manpage

Please let me know what you think about that, idea 1 is quite easy and can be easily added to 5.0.

I think we can create a table in the code that is used to parse rules instead of the current hard coded DetectProtoParse() logic. E.g. something like:

struct {
    const char *name;
    uint8_t proto;
    uint8_t flags;
} proto_table[] = {
    { "tcp", IPPROTO_TCP, 0 },
    { "tcp-pkt", IPPROTO_TCP, DETECT_PROTO_ONLY_PKT },
    { "tcp-stream", IPPROTO_TCP, DETECT_PROTO_ONLY_STREAM },
}

Then walk this table both in parsing and for parsing output.