On 02/20/2013 10:37 PM, Francisco Slavin wrote: > So the complexity of writing SCAP content is an issue that's been > periodically raised in various parts of the community. Is anyone aware > of what the current recommended best-practice is? I'm not so sure that > solving the problem of overly-complex XML by adding yet another layer > of XML is really solving the problem; at some point (usually > troubleshooting) it just becomes added complexity.
My personal recommendation is to use a suitably-devised XML representation (or as many as one needs) and transform via XSLT. XML is not essential, just easier, particularly at the final stage that produces SCAP-compliant documents. This does not preclude representations other than XML — it's just more difficult to parse non-XML on its way to becoming XML. This difficulty may simply be a personal shortcoming. Use of XML also affords schema-driven content editing. While they likely exist, I am unaware of any alternate syntaxes that can coerce correctness at content creation time solely using static documents in the fashion of XML schemata. I cannot recommend any other recommendations, particularly any using SCAP "languages" natively or via telekinesis. Any departure from something simple that can be easily wielded by someone whose expertise lies in system configuration rather than arcane "languages" is wacky, which is the current state of affairs in SCAP. > At some point early in our involvement with SCAP we mucked around with doing > something similar, but with a non-XML-based domain-specific language called > SC [1] (and its compiler, SCC. This was before we knew there was a scanning > tool out there of that name; early days, etc.). The goal was to have a more > human-readable syntax for authoring content which would then be compiled into > OVAL. At the time we hadn't started tackling XCCDF. At some point I even > rolled up an Eclipse plug-in to allow for auto-completion and > dropdown-niceties for the SC language, though that plug-in never made it to a > releasable state. That sounds perfectly reasonable. > The project itself is neither here nor there, but from past experience going > down the road of "Let's add another authorship layer to make this easier" > there are some pitfalls to look out for. The primary one is the problem of > testing your end-content that has been produced. To drop into the narrative > for a moment: > So you [the content author/protagonist here] author your content in a simpler > manner. You have some auto-complete, the syntax is simple, life is good. > You then run some magic to get the end content compiled (or transformed via > XSLT). Now you've got your messy XCCDF/OVAL/whatever, but thanks to your > easy-authorship approach you don't really have to look at that. You test the > content out in your tool-of-choice, but drat! It didn't do what you > expected. What went wrong? Was it: > A ) The original content you wrote has a bug > B ) The transform/compiler you leveraged has a bug > C ) The tool you leveraged has a bug > > In order to track this down you really need an in-depth knowledge of the > XCCDF/OVAL. That's what your tool is consuming, so to figure out if the > problem is that content or if it's the tool requires really looking at the > XCCDF/OVAL. In order to debug content, your content author will still need > to have some deep knowledge of XCCDF/OVAL. Yes, particularly at C, and less likely at A if the original content is not something wacky. Were SCAP not a consideration, how much easier would this become? > I'm sure everyone on this list has written a lot more XCCDF & OVAL than > myself, so I'll defer to the community's expertise here. I'm just not sure > there's a practical way to avoid having XCCDF be levied on content authors; > the best solution may be to just get a good editor UI set up. I believe SCAP > Workbench [2] takes that approach. I think this can only be successful if OVAL were to disappear, and the X in XCCDF actually lived up to its commitments. _______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
