Yes -- please push as a bugfix. The utils/verify-references.py script (which must be invoked from the output directory using "../utils/verify-references.py" ) has the logic to detect these kinds of things. Perhaps we should add it to the make-validate Makerule to catch these kinds of (non-obvious) oopses...
On 04/21/2013 11:35 PM, Shawn Wells wrote: > On 4/21/13 10:39 PM, Jeffrey Blank wrote: >> Rule selection specified by a Profile overrides selection specified in >> the Rule itself. >> Any Rules which are not explicitly marked as "selected=false" will be >> evaluated. >> >> Thus, our convention is to mark all Rules as "selected=false" in the >> actual Rule attribute, because we wish to have Profile-driven >> evaluation. (And all of our Profiles only ever feature "selected=true".) >> >> Please see page 20 of >> http://csrc.nist.gov/publications/nistir/ir7275-rev4/NISTIR-7275r4.pdf >> >> Note there that the default is "true" for selection in a Rule. So, if >> we weren't intentionally de-selecting each Rule using its attribute >> (selected=false), even in a Profile-driven evaluation (which did not >> include the Rule!) it would default to true and be evaluated. Yes, >> this would be quite unexpected. This is explained by the fact that >> the earlier versions of XCCDF has no Profiles. The thought (at that >> time, from what I can infer) is that end-users would receive a body of >> XCCDF and then select/de-select (using tooling) what they wanted (and >> save the resulting XCCDF content as their own). >> >> But that is not the way it turned out. The way it turned out was that >> widespread authoring/modification of XCCDF never really occurred, and >> instead XCCDF really only took hold as a means of expressing a small >> number of government security baselines (all of which were expressed >> as Profiles, rarely modified, due to the inadequacy or lack of >> adoption of any tooling for authoring). >> >> So I hardly blame you for being confused. The decision tree for XCCDF >> evaluation is vastly more complicated than needed for any use case >> I've ever seen (or could practically imagine). > > Jeff pinged me offline and it turns out this was caused by the id tag > within the OVAL not matching the filename. I threw together a patch here: > https://lists.fedorahosted.org/pipermail/scap-security-guide/2013-April/003061.html > > _______________________________________________ > scap-security-guide mailing list > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide _______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
