Conversation
So that we can write enip.revision: 0x203 Ticket: 6645
Ticket: 6647 Allows keywords using integers to use strings in signature parsing based on a rust enumeration with a derive.
Ticket: 6648 Like &0x40=0x40 to test for a specific bit set
Ticket: 6628 Document the generic detection capabilities for integer keywords. and make every integer keyword pointing to this section.
catenacyber
force-pushed
the
detect-integers-6644-v11
branch
from
cd32edc to
27093cc
Compare
|
Information: QA ran without warnings. Pipeline 17685 |
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #10222 +/- ##
==========================================
+ Coverage 82.18% 82.23% +0.04%
==========================================
Files 977 978 +1
Lines 271894 272012 +118
==========================================
+ Hits 223465 223698 +233
+ Misses 48429 48314 -115
Flags with carried forward coverage won't be shown. Click here to find out more. |
jufajardini
left a comment
jufajardini
left a comment
There was a problem hiding this comment.
Picked up two things for in the docs, pointed them out inline.
(Really want to see this merged!)
| The integer value can be written as base-10 like ``100`` or as | ||
| an hexadecimal value like ``0x64``. | ||
|
|
||
| The most direct exemple is to match for equality, but there are |
There was a problem hiding this comment.
nit typo: example
(sorry for not picking that up before)
| websocket.opcode:text; | ||
| websocket.opcode:1; # behaves the same |
There was a problem hiding this comment.
For a future work: I think that this deserves a ticket for us to ensure that all such cases have proper documentation indicating that both ways work, and what are the accepted text values for each.
There was a problem hiding this comment.
This should rather be part of the dev/review process then.
Otherwise, this ticket can never be closed as there will always be new future keywords
There was a problem hiding this comment.
Oh, not for this ticket, indeed!
Do you mean that as part of the review process for new keywords, we should do this?
I was thinking of adding a ticket for when this work is merged, someone review the documentation we have and update it as needed...
There was a problem hiding this comment.
But this is a new feature brought by a commit in this PR so no keywords use it now.
One in the websocket PR and 2 in the Enip PR do use this
There was a problem hiding this comment.
AH! Sorry for the noise, then 🙇🏽
|
|
||
| An optional operator can be specified; if no operator is present, the operator will | ||
| default to '='. When a relational operator is used, e.g., '<', '>' or '<>' (range), | ||
| the bsize value will be compared using the relational operator. Ranges are inclusive. |
There was a problem hiding this comment.
We should update this line where it says that ranges are inclusive, right?
There was a problem hiding this comment.
This should be its own ticket, and back ported.
Do you create it or should I ?
There was a problem hiding this comment.
|
Continued in #10234 |
3 participants
Link to redmine ticket:
https://redmine.openinfosecfoundation.org/issues/6644 and all subtickets
https://redmine.openinfosecfoundation.org/issues/6645
https://redmine.openinfosecfoundation.org/issues/6646
https://redmine.openinfosecfoundation.org/issues/6647
https://redmine.openinfosecfoundation.org/issues/6648
https://redmine.openinfosecfoundation.org/issues/6628
Describe changes:
#10197 with code review taken into account (better doc)