Closed jpohls1 closed 7 months ago
The YR_RULES type is opaque since https://github.com/Hugal31/yara-rust/commit/43d0be1cdd8bafaffa26cfb0c247da573fe1a818
It was made opaque mostly for codegen size reasons, so we can totally decide to expand it once again. This would give access to the rules_table field, which would be imho preferred, as it avoids adding C code for the bindings.
I am not a big fan of adding a mandatory dependence to cc. Is yr_rules_foreach
the only public interface we got or can we safely re-implement it in Rust?
Cool, didn't know about 43d0be1cdd8bafaffa26cfb0c247da573fe1a818, thanks @vthib. Removed the line that made YR_RULES opaque from build.rs
and implemented a RuleIterator
in the same spirit as the existing Iterators in the code.
@Hugal31 please let me know whether further changes are required.
@Hugal31 could you please release a new version that includes this change?
This PR fixes #135. It includes an updated
tutorial.rs
showcasing how to iterate over the compiled ruleset and disabling certain rules. This feature is crucial for implementing custom rule filters in client-side applications.Please let me know any feedback and thanks for creating these bindings!
Implementation details
On the new get_rules.c file
The approach taken by existing iterators such as
TagIterator
is difficult to apply, because the rules_table is not properly exposed via bindgen. We just have a binary blob to work with:Therefore, I created a new file
get_rules.c
which uses theyr_rules_foreach
macro to retrieve the rules from the ruleset. This is inspired by the Go bindings.Since we need to compile this file in any case, the
cc
build-dependency is now mandatory, hence the changes in theCargo.toml
andbuild.rs
.On the new RulesetRule struct
The existing
Rule
struct represents a rule that matched during a scan. It would have involved some more refactoring to lift this assumption. I went with the less invasive change here and created a newRulesetRule
struct.