> tag is basically just a reference to a <value> somewhere. I know > I've caught some flack for the JSON usage, but it was a practical way > to get things implemented. Given that we can't use arbitrary XML to > keep the document all-XML, and that whatever we do within a <fix> tag > ends up being pseudo-standard at best, JSON has proven to be a > lightweight option for use as an intermediate solution.
We can do whatever we want with XML in our authoring language, and we're not writing in any particular schema (as Gary has pointed out). As far as I'm concerned, final output should be valid XCCDF, but you can do anything you want with XML until then. (And tooling that prepares the fixes for execution can take care of preparing the environment to run the bash script, such as instantiating environment variables.) And your perception is correct: attempts to introduce JSON (or Perl) into SSG should expect serious resistance. Had we started all development in JSON, then I'd say the same about XML. > I know there was a discussion about having a better way to uniquely > identify fixes besides just a path to a script on a system. Possibly > some UUID which in turn maps to a script somewhere? I want fixes to identify what they're for (by referencing a Rule id), not the other way around. What <fix> to run is not the concern of the baseline or guidance creator, and remediation is not the raison d'etre of scap-security-guide. But we're happy to work closely together and include simple bash fixes inside the project. In essence, I would encourage remediation developers to refer to items in the input/system and input/services (and input/profiles) directories, and develop tooling that permits combination and integration with the content generated from there. > If there's a > standards-based way to do this it would be great, but with how > immature the <fix> aspect of XCCDF is I'm not sure if that option is > there. Having some pseudo-standard in place here gives us > flexibility to add fields or metadata as needed without invalidating > the XCCDF document, whereas if there were raw BASH content in the > <fix> tag we would not have that sort of flexibility. My motivation to look into the "right" way to do remediation will be far higher when someone can assure me that the OVAL has actually been QA'ed. Could you advise on current status of this? Is this still a dependency of CLIP? > I'll chime in again with an opinion that I think BASH and non-XCCDF > content should live in files external to the XCCDF, and simply be > referenced from the XCCDF. Absolutely! Like we do now in SSG, for development. I'm assuming there will be one XCCDF file from SSG with simple bash fixes, and one without. In fact, that reminds me to adjust the Makefile so that what is perceived as the "main" one does not include fixes. > I'll chime in again with an opinion that I think BASH and non-XCCDF > content should live in files external to the XCCDF, and simply be > referenced from the XCCDF. I know this is a discussion that's been > had a few times, and this may be a battle I've already lost, so kick > me if I shouldn't be bringing this back up. Definitely -- no development of <fix> tags is occurring inline with the main content. The fix tags live inside their own directories away from where the usual XCCDF content is written. I don't expect issuers of baselines to include <fix> tags, and the act of adding fixes is intentionally seperable/separated. It may be possible to ship one version of the XCCDF file with bash fixes, and some tooling may be able to process this, but this shouldn't preclude any other approaches. _______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
