Need backwards compatible logic baked into YARA as a META tag

[plusvic]

From dar...@kindlund.com on May 10, 2012 21:32:30

What steps will reproduce the problem? In YARA v1.6, bitwise operators were introduced (e.g., &, |).

In YARA v1.5 and older, any rules supplied containing bitwise operators will cause those engines to explicitly fail. What is the expected output? What do you see instead? Instead of failing to load all YARA rules, it would be helpful if YARA respected a META tag like:

rule new_rule {
meta:
min_version = 1.6
}

rule old_rule {
meta:
min_version = 1.5
}

Then, if you run these rules against YARA v1.5 engine, only the "old_rule" would get loaded, while if you ran these rules against the YARA v1.6 engine, both "new_rule" and "old_rule" would get properly loaded and used.

Essentially, rather than having YARA v1.5 fail outright, it could just ignore incompatible rules but proceed to process other supported rules, accordingly. What version of the product are you using? On what operating system? v1.4, Linux 64-bit
v1.5, Linux 64-bit
v1.6, Linux 64-bit Please provide any additional information below.

Original issue: http://code.google.com/p/yara-project/issues/detail?id=48

[plusvic]

From plus...@gmail.com on May 11, 2012 05:25:34

Even if this feature is implemented it won't apply to version 1.6 and lower. I mean, in version 1.7 you will be able to ignore new syntax included in version 1.8, but version 1.6 and lower will fail anyway.

Could you explain a little more your real-life situation where this feature is needed? Why not keeping your YARA version up to date?

[plusvic]

From dar...@kindlund.com on May 11, 2012 07:09:37

Sure, I'd be happy to provide more detail:

Assume you have 1,000's of "systems" all with YARA installed. Do you really think its realistic that you should have to "upgrade" those instances of YARA, simultaneously? If you have a directory containing your "master YARA rule list" that is being replicated out to each of these systems, before you upgrade any of those rules to leverage new features, you have to make sure that all versions of YARA across all 1000 systems are updated, accordingly. Currently, to get around this, you'd have to externally maintain different "versions" of the "master list" for each version of YARA, which makes overall rule management more painful than it needs to be.

Yes, if v1.7 started implementing this feature, you would still have to deal with this painful setup at least until all your systems are upgraded to v1.7. But, once that happens, when v1.8 and later is released, the process becomes much more manageable.

Lastly, if you're accepting YARA rules for a third-party, having an option to require min_version on each rule makes it easier to perform initial rule validation back to that third-party. For example, if you're running YARA v1.4 and the third-party uploads v1.6 YARA rules, we can have YARA output an explicit "unsupported version" error message, rather than vague syntax errors, which we then have to decipher and translate as "unsupported version", accordingly.

Does this make sense?

[plusvic]

From dar...@kindlund.com on May 11, 2012 07:13:02

To clarify further, if YARA v1.7 implemented the "min_version" meta tag, you could then provide a command-line options like:

--enforce_version

If (--enforce_version) were present, YARA would explicitly generate errors if it encountered any rule with min_version higher than its current version.

If (--enforce_version) were NOT present, then YARA would silently ignore any rules where min_version is higher than its current version.

[plusvic]

From plus...@gmail.com on May 11, 2012 16:05:50

Ok, I see your point. But I think, I would prefer some kind of preprocesor directives in the style of the C language. For example:

#if yara_version >= 1.7

some rules here using new features available in 1.7

#endif

That would be more flexible. What do you think?

[plusvic]

From dar...@kindlund.com on May 11, 2012 17:08:49

Sure, that makes complete sense. Thanks for your time!

[plusvic]

From plus...@gmail.com on August 15, 2012 09:11:59

This will be solved with a C-style preprocessor with conditionals. See issue 61 .

[plusvic]

From plus...@gmail.com on August 15, 2012 09:12:16

Status: WontFix