Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mqtt rust keywords 4863 v2 #11374

Closed

Conversation

catenacyber
Copy link
Contributor

Link to ticket: https://redmine.openinfosecfoundation.org/issues/
https://redmine.openinfosecfoundation.org/issues/4683

Describe changes:

  • mqtt: move keywords to pure rust

SV_BRANCH=OISF/suricata-verify#1920

#11316 with more fixing commits

@satta could you say if you approve ?

So that MQTTTypeCode::CONNECT does not become c_o_n_n_e_c_t
As needed for MQTTTypeCode which accepts both CONNECT uppercase
and unassigned lowercase
for easier later matching
Ticket: 4863

On the way, convert some keywords to use the first-class integer
support.
And imports in pure rust the support for multi-buffer.
There was a typo that version 3 was tested twice


mqtt.flags
----------

Match on a combination of MQTT header flags, separated by commas (``,``). Flags may be prefixed by ``!`` to indicate negation, i.e. a flag prefixed by ``!`` must `not` be set to match.

mqtt.flags uses an :ref:`unsigned 8-bits integer <rules-integer-keywords>`
Copy link
Contributor

@satta satta Jul 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd consider this statement confusing unless also showing an example to illustrate that both negatable flag strings as well as numeric values can be used here.

Why would someone use the numeric value here? I thought the idea of the rule language is to abstract from literal byte values to semantic identifiers.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why would someone use the numeric value here? I thought the idea of the rule language is to abstract from literal byte values to semantic identifiers.

You can use either numeric or semantic identifier...
I am not sure it makes sense to use numeric, but it is available

Copy link
Contributor

@satta satta Jul 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. Maybe I was expecting an example like given for mqtt.type.

let ctx = DetectUintData::<u8> {
arg1,
arg2,
mode: DetectUintMode::DetectUintModeBitmask,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice. This is surely powerful, but really needs documentation or examples. Took me a bit to get my head around it!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I was referring to the Rust API (DetectUintMode and what tooling the Rust helpers provide). I think for common cases like negatable flags it would be helpful to see an example so the wheel will not be reinvented again ;)

@satta
Copy link
Contributor

satta commented Jul 1, 2024

@satta could you say if you approve ?

First of all, thanks a lot for this porting work! It must have taken a lot of work to replicate, streamline and optimize things to make everything consistent with what you have planned for detection code in Rust! 🙌🏻

I have coarsely looked through the code and I must say that it's too much to really review in detail, in particular when unfamiliar with all the detection support that was established in the meantime. But I think I understand how the C concepts are mapped to Rust and how the interface works, while I am still stumped by some of the deeper Rust-isms (like any of the derive stuff!). It would be nice to get some documentation for all the helper code at some point so it's less likely to reinvent the wheel.

Having noted that, I would approve these changes from my point of view; the code looks complete, the tests succeed and suricata-verify is also happy.

@suricata-qa
Copy link

ERROR:

ERROR: QA failed on build_fetch.

Pipeline 21348

@suricata-qa
Copy link

ERROR:

ERROR: QA failed on build_fetch.

Pipeline 21349

@victorjulien victorjulien added the needs rebase Needs rebase to master label Jul 3, 2024
@catenacyber
Copy link
Contributor Author

First of all, thanks a lot for this porting work! It must have taken a lot of work to replicate, streamline and optimize things to make everything consistent with what you have planned for detection code in Rust! 🙌🏻

Thanks Sascha

Having noted that, I would approve these changes from my point of view; the code looks complete, the tests succeed and suricata-verify is also happy.

Thanks for the SV tests : as a matter of facts, they caught a bad copy paste from me where I put a keyword match function into another

Continued in #11430

@catenacyber catenacyber closed this Jul 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs rebase Needs rebase to master
Development

Successfully merging this pull request may close these issues.

4 participants