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:
> At VirusTotal, we have been running YARA-X alongside YARA for a while, scanning millions of files with tens of thousands of rules, and addressing discrepancies between the two.
This is pretty encouraging as far as compatibility. I hope they keep doing this.
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?
Well EOL usually means something like “end of official support, active development, and security patches” so the owner/creator/foundation usually chooses when.
“Dead” is usually a colloquialism, so if enough people call it dead, it is.
Whoever owns the canonical repo (also, any relevant trademarks) has a lot of power in this situation. The community can certainly fork it, but then you start asking if the fork is a new project.
The article backs on the claim in the title, making the title kind of clickbait:
"Is YARA really dead?
Despite the dramatic title of this post, YARA is not actually dead. I’m aware that many people and organizations rely on YARA to get important work done, and I don’t want to let them down.
YARA is still being maintained, and future releases will include bug fixes and minor features. However, don’t expect new large features or modules. All efforts to enhance YARA, including the addition of new modules, will now focus on YARA-X."
The official maintainers say they won't be maintaining the repo any more. Anyone else is always welcome to fork and form their own project to continue to maintain the software.
If all you have is a Rusty hammer, everything is a nail.
Third party module dev is harder now for yara-x. And I wonder how the python module will turn out.
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.
Crowsresponse by crowdstrike is better too but it still has limits. Python is the best way to yara.
https://virustotal.github.io/yara-x/docs/writing_rules/diffe...
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.