docs: document the YR_RE_SCAN_LIMIT regular expression scan limit#2223
Open
munzzyy wants to merge 1 commit into
Open
docs: document the YR_RE_SCAN_LIMIT regular expression scan limit#2223munzzyy wants to merge 1 commit into
munzzyy wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #2194.
The regexp engines cap how much data they scan at
YR_RE_SCAN_LIMIT(4096 bytes, defined inlibyara/include/yara/limits.h), so a match that needs more than that simply isn't reported. @plusvic pointed at the constant in the issue thread, but the limit isn't mentioned anywhere in the docs, which was the reporter's actual complaint: rules with wide wildcards fail silently and there's nothing in the manual explaining why.This adds a warning box to the "Regular expressions" section of writingrules.rst stating the default limit, the silent-miss behavior, and that it can be raised at compile time.
Checked against HEAD (fa372eb) before writing the note:
/foo.*bar/over a file withfooandbar4000 bytes apart (matches) and one with them 5000 bytes apart (no match, no error, exit 0)CPPFLAGS='-DYR_RE_SCAN_LIMIT=8192': the 5000-byte gap now matches and a 9000-byte one doesn't, so the compile-time override wording is accurate