Need backwards compatible logic baked into YARA as a META tag

[GoogleCodeExporter]

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 reported on code.google.com by dar...@kindlund.com on 10 May 2012 at 7:32

[GoogleCodeExporter]

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?

Original comment by plus...@gmail.com on 11 May 2012 at 12:25

[GoogleCodeExporter]

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?

Original comment by dar...@kindlund.com on 11 May 2012 at 2:09

[GoogleCodeExporter]

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.

Original comment by dar...@kindlund.com on 11 May 2012 at 2:13

[GoogleCodeExporter]

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?

Original comment by plus...@gmail.com on 11 May 2012 at 11:05

[GoogleCodeExporter]

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

Original comment by dar...@kindlund.com on 12 May 2012 at 12:08

[GoogleCodeExporter]

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

Original comment by plus...@gmail.com on 15 Aug 2012 at 4:11

[GoogleCodeExporter]

Original comment by plus...@gmail.com on 15 Aug 2012 at 4:12

• Changed state: WontFix