The risk with such rewrites is ending up with a Python 3 situation and an ecosystem split. Sounds like YARA-X is (mostly) a stricter subset of YARA, and it's easy to write rules that are valid for both:<p><a href="https://virustotal.github.io/yara-x/docs/writing_rules/differences-with-yara/" rel="nofollow">https://virustotal.github.io/yara-x/docs/writing_rules/diffe...</a><p>Although I wonder how long it'll stay that way? It'll be very tempting to add new features to YARA-X that won't be backported to YARA.
For curious onlookers, here's an explanation of what Yara does:<p><a href="https://virustotal.github.io/yara/" rel="nofollow">https://virustotal.github.io/yara/</a>
After reading the article, a fun thought popped into my head.
Who has the right to determine if a project like this is dead or EOL'd? Is it the original author to make that declaration or when it is under BSD license, wide community-use, and support -- when does a project like this truly become dead or EOL'd?
If all you have is a Rusty hammer, everything is a nail.<p>Third party module dev is harder now for yara-x. And I wonder how the python module will turn out.<p>Neither 3rd party/go clients nor the official virustotal C client could meet my requirements, I had to write a scanner in python on at least two different times and having to do it again soon. The main issues are resource usage, result shuffling and supporting very large proprietary ruled that depend on specific yara modules.<p>Crowsresponse by crowdstrike is better too but it still has limits. Python is the best way to yara.