On Sunday, June 02, 2013 1:57 PM, Jeff Blank wrote:
Francisco, Shawn,
What was your thinking behind the common-fix elements?
I believe those elements
were an attempt at allowing for function re-use. The inspiration was a set of examples
posted to this list by Simon Lukasik (of OpenSCAP fame). The discussion that led up to my
patch was in this thread:
https://lists.fedorahosted.org/pipermail/scap-security-guide/2013-April/0...
Please also see (shortly) my new patches for fix insertion.
I've re-written the fix insertion stuff. So that people can "declare"
their use of particular environment variables in bash (using a bash function).
Then the reworked combinefixes.py will pick up on the declaration and assign an XCCDF
<sub idref/> to that variable. <sub idref/> is how oscap supports inserting
particular values inside a fix.
For unit testing (still incomplete), the bash function "needs" should grab the
right value from XCCDF and populate it accordingly.
Do we still need the fix-common elements, to insert them into the XCCDF?
I like to delete unused code.
I need to look through your new patches to properly respond here. The original goal was
to populate some top-level <plain-text> elements with common functions. Per
Simon's examples, the <sub idref/> can refer directly to these
<plain-text> elements. This follows the way Mike P's original SSG-targeted
remediation scripts were authored in Aqueduct:
https://fedorahosted.org/aqueduct/browser/trunk/compliance/Bash/SSG/dev
Where there were a series of scripts ending in "common" which were referenced as
appropriate by the other ".sh" scripts.
My approach was just to drop all of the "common" content into <plain-text>
elements and have the ".sh" content be specific to individual <fix>
elements.
- Francisco
Jeff