(imported topic written by SystemAdmin)
I know there have been posts here in regards to using a reference to a pre-existing relevance in another fixlet and that you’ve had a ‘heated debate’ internally around the subject as well and that as a result you came to the understanding that references are ‘bad’ and that you can’t easily make them work in your current infrastructure.
The concern I have about not using references goes back to the very painful (and sometimes dangerous) notion of copy and pasting identical code chunks around in scripts. This is a known issue where you will subsequently change an element of the code someplace (finding a bug in what you thought was rock-solid code, or perhaps having to deal with new circumstances) and in many cases, want to (or even need to) go back to every instance where that was used and make the same change.
In my situation, I am visualising the need to use a number of somewhat convoluted expressions (and sometimes negated) in multiple Fixlets and possibly an analyses or two. How can I safely manage this code?
Now, I understand the issue of you not wanting to have one Fixlet’s relevance used in a second, as when you change the first, you would then have to decide how or if to change the second (and do they have the rights, etc.). However, you currently do exactly that for Baselines. You are essentially storing a reference to a Fixlet within a Baseline and actually even check for modifcations withing the Baseline for when any of the original Fixlets are modified. How is this very different from using a reference to a relevance from another Fixlet?
I would like to see the ability to store relevances on their own in the database and have the console keep track of the use of the relevances (similar to Baselines). This would then allow me to write things like:
{Tracked_relevance “Extract version number for Symantec AV” > “11.00.0” as version}
and use the same reference for multiple tests. The inspector “Tracked_Relevance” would merely make use of the stored ‘master’ relevance and for your purposes, internally, you would just replace the code when you package the Fixlet. An additiona (and important) consideration would be to add a HUGE amount of clarity to the relevances. I don’t know how many times my eyes and mind have wandered when trolling through a lengthy relevance including"…first 3 of preceding text ‘:’ of last 26 of…" or “…key “HKLM\xxxxx\yyyyy\zzzzz” of registry…” where I would much rather see the simple line as shown in my example, above.
If the ‘master’ relevance changes (possibly fixing an incorrect element) in the source database, I would then have the option to create a new master based on the ‘old’ settings (and point any affected Fixlets to it) or modify the fixlets to re-synch with the (now correct?) master relevance. Job done.
Discuss.
